Lage:
Unternehmen ist etwa 50 Personen. Die Gesamtzahl der Entwickler beträgt etwa 15, aufgeteilt in drei Teams. Team 1 hat fünf Entwickler, die hart daran arbeiten, ein neues System aufzubauen. Die Deadline ist gestern, was bedeutet, dass es keine bestimmte Dealine gibt, aber je früher wir fertig sind, desto besser.
Wir haben keinen Scrum Master oder Projektmanager. Ich bin der erfahrenste Entwickler im Team und werde vom CEO als Leiter des Teams angesehen, ich leite das wöchentliche Meeting mit dem CEO und anderen Stakeholdern usw.
T ist seit drei Wochen ein neues Teammitglied. Er spricht mit dem CEO über etwas, das er mit dem neuen System sehr gerne macht, das aber derzeit nicht auf der Aufgabenliste steht. Der CEO ist begeistert und fragt, wie lange T dafür brauchen wird. T sagt, es wird ungefähr einen halben Tag dauern. „Großartig“, antwortet der CEO. "Komm und zeig es mir morgen".
Morgen kommt und die Aufgabe ist noch nicht beendet. Also will T am nächsten Tag mit der Aufgabe fortfahren.
Meine Gefühle:
Ich habe das Gefühl, dass T die Aufgabe absichtlich niedrig eingeschätzt hat, um den CEO dazu zu bringen, ja zur Aufgabe zu sagen. Allerdings hat T jetzt keine Zeit für die anderen geplanten Aufgaben, und seine neue Aufgabe nimmt eine unbekannte Zeit in Anspruch. Ich denke, das ist ein Problem für die Planung, und es sollte von T gelöst werden.
Frage:
Was soll ich machen?
Meine Antwort:
Ich bin wirklich hin- und hergerissen, wie ich mich verhalten soll:
Aktualisieren
Wow, tolle Antworten! Ich habe sie alle hochgestuft (leider nicht öffentlich sichtbar). Ich hatte ein bisschen Angst, dass ich meine wahrgenommene Rolle zu ernst nehme, aber ihr habt mir Feedback gegeben, damit ich weiß, dass ich auf dem richtigen Weg bin. Ich habe bereits mit dem CEO über den Scope Creep gesprochen und werde dies auf jeden Fall weiter tun. Nochmals vielen Dank!
Sie werden als Teamleiter wahrgenommen, also müssen Sie diese Rolle übernehmen, wenn es niemanden mit diesem formellen Titel gibt. Sie treffen sich bereits regelmäßig mit dem CEO, als ob Sie diese formelle Rolle hätten, also leiten Sie standardmäßig das Team.
Ich schlage vor, dass Sie mit dem neuen Teammitglied sprechen, herausfinden, ob es realistisch ist, dass er die neue Fähigkeit in einem realistischen Zeitrahmen entwickeln kann, und dann die Optionen mit dem CEO besprechen und Ihre Ergebnisse erläutern. Wenn es angemessen ist, die Entwicklung innerhalb eines kurzen Zeitraums abzuschließen, kann der CEO der Fortsetzung der Arbeit zustimmen. Wenn Ihr Rat lautet, dass es unwahrscheinlich ist, dass es abgeschlossen wird, sollten Sie eine Vorgehensweise empfehlen, z. B. das Stoppen der Entwicklung oder das Verschieben auf eine spätere Phase oder sogar das Zuweisen von Zeit dafür, wenn das Feature ausreichend wichtig ist. Was Sie angesichts Ihrer De-facto-Rolle nicht tun können, ist, die Situation zu ignorieren – sonst erfüllen Sie Ihre Rolle nicht.
Um einen Schritt zurückzutreten, mache ich mir Sorgen, dass ein Entwickler das Projekt auf diese Weise aus der Bahn werfen konnte. Noch einmal, da Sie abgesehen vom Namen der Teamleiter sind, sollten Sie die Entwicklungsaktivitäten kontrollieren und sicherstellen, dass alle vorgeschlagenen Änderungen des Umfangs einer Auswirkungsbewertung unterzogen werden, bevor sie genehmigt werden. Wenn Sie Ihre Autorität jetzt nicht durchsetzen, dann werden Sie Anarchie innerhalb des Teams haben, wobei andere Entwickler (und besonders dieser neue) zum CEO gehen, wenn sie an etwas Neues denken, das sie dem Umfang und dem Projekt hinzufügen können wird niemals liefern, weil es immer etwas Neues und Glänzendes zu bauen gibt. Vielleicht müssen Sie den vereinbarten Umfang vervollständigen und dann eine weitere Version haben, in der neue Ideen hinzugefügt werden können?
Teamleiter sind es nicht nur, weil sie offiziell als besagter Teamleiter bezeichnet wurden. Sie führen, weil sie die Rolle übernehmen und einmal angenommen haben, dass sie de facto der Projektmanager sind und genau so für das Projekt verantwortlich und rechenschaftspflichtig sind, als wären sie offiziell ernannt worden. Sie können das Team nicht führen, als Teamleiter angesehen werden, sich dann aber vor der Verantwortung und Rechenschaftspflicht darin drücken.
Und Sie haben einen fatalen Fehler gemacht: Sie haben T und dem CEO erlaubt, sich in Ihren Bereich einzuschleichen. Und jetzt haben Sie es mit den Auswirkungen von Scope Creep zu tun. Nicht mehr, nicht weniger.
Die gute Nachricht ist, dass Scope Creep den Besten von uns passiert. Und Erholung steht Ihnen zur Verfügung. Sie müssen sich mit dem CEO zusammensetzen und darlegen, was Sie beobachtet haben, dass T und der CEO eine außer Kontrolle geratene Änderung eingeführt haben, die das gesamte Projekt als Ganzes gefährdet. Obwohl die Änderung eine super Idee sein mag, muss ihre Einführung "unter Kontrolle" sein, dass sie vom breiteren Team analysiert, Auswirkungen identifiziert und verstanden, Zeitplan und Kosten entsprechend angepasst, Dinge neu priorisiert, Schätzungen und Planungswerte ganzheitlich vereinbart werden das breitere Team, und dann die Arbeit planen lassen. Sie müssen Ihren CEO über Scope Creep und Scope Control „lehren“ und wie wichtig diese Dinge sind, und Ihren CEO dazu bringen, dies voranzutreiben.
Danach müssen Sie sich mit dem Rest des Teams treffen, vielleicht auch mit T allein, und angemessene Erwartungen in Bezug auf diese Art von Dingen setzen und es nie wieder tun. Wenn Sie das Gefühl haben, dass Sie diese Autorität nicht haben und das Team Ihnen nicht folgt, dann sind Sie nicht der Anführer des Teams.
In Ermangelung einer formellen Autorität müssen Sie hier vorsichtig vorgehen. Sie können schlussfolgern, wie der CEO Ihre Rolle sieht, und es ist möglicherweise nicht so, wie er sie sieht. Wenn Sie einen formellen Manager haben, der zwar kein leitender Entwickler ist, aber dennoch Ihr Chef ist, wäre ich vorsichtig, wenn Sie formelle Autorität annehmen würden, die Sie nicht haben. Ich stimme anderen zu, dass es in Ihrem besten Interesse ist, Führungsqualitäten zu demonstrieren, aber Sie müssen dies informell tun, zB indem Sie einfach die Hindernisse beseitigen und Dinge in die Tat umsetzen. Mein Bauchgefühl ist es, mit Ihrem Kollegen zusammenzuarbeiten und ihn auf Augenhöhe zu behandeln, es sei denn, Sie stehen formell über ihm. Selbst wenn Sie Senior-Entwickler und er Junior-Entwickler sind, sind Sie nicht sein Chef, wenn Sie beide demselben Manager unterstellt sind, und er wird es nicht zu schätzen wissen, dass Sie sich so verhalten, als ob Sie einer wären. Versuchen Sie zu verstehen, was ihn blockiert, bieten Sie ihm Hilfe an, erinnern Sie ihn an die Gefahren, zu viel zu versprechen und zu wenig zu liefern. Ich gehe davon aus, dass Sie ihm helfen wollen und im Team denken und ihm nicht einfach den Skalp nehmen wollen. Es kann sein, dass Sie die Arbeit am Ende selbst erledigen müssen, aber stellen Sie sicher, dass dies bekannt ist, ohne ihm die Nase zu reiben. Schließlich ist es nicht Ihre Aufgabe, ihn zu sanktionieren, selbst wenn er tatsächlich unterdurchschnittlich abschneidet, wenn Sie nicht sein Chef sind.
Kurzfristig können Sie T genug Seil geben, um sich zu erhängen. Sie leiten die wöchentlichen Meetings, machen Sie ihn also für die Arbeit verantwortlich, die er nicht erledigt, wenn dies den Projektzeitplan/Kosten/Umfang/Risiko/usw. betrifft. Wenn sein Abdriften kein Problem verursacht, dann kein Schaden und kein Foul, aber wenn es zu Verzögerungen führt, versuchen Sie nicht, ein „netter Kerl“ zu sein, indem Sie ihn decken.
Längerfristig hat Ihr Projekt einige große Herausforderungen:
Im Idealfall sind Sie in der Lage, diese Kernprobleme anzugehen, um zu verhindern, dass T (oder jemand anderes) abtrünnig wird und ohne Kontrolle Umfang oder Kosten oder was auch immer hinzufügt. Das kostet einige Mühe, erspart Ihnen aber langfristig Probleme, denn irgendwann, wenn Ihr Team nicht diszipliniert ist, wird irgendjemand das Projekt scheitern lassen.
Da Sie nicht der offizielle Leiter sind, können Sie am besten mit dem Projektmanager oder Scrum Master sprechen. Sprechen Sie über die Bedeutung des Projekts und schlagen Sie vor, das Off-Track-Projekt zeitlich zu planen. maximal noch einen Tag, dann muss das Team weiterziehen. Darüber hinaus kann das Team dieses Projekt nach der Lieferung überprüfen.
Die neue Person kann dieses Projekt starten, weil sie oder er noch nicht über das Domänen-Know-how verfügt und beweisen möchte, dass er oder sie gut für das Unternehmen ist.
Dies könnte ein Test Ihres CEO gewesen sein – er hat Sie nicht zu Ihrer Meinung zu Ts Idee befragt – obwohl er Sie als Teamleiter und damit als Experten sieht.
Ich würde mit Ihrem CEO über ein bisschen (!) Formalismus bei der Planung neuer Anforderungen sprechen, damit mehr als ein Entwickler darüber nachdenken kann und die Aufwandsschätzung entweder nur von einem erfahrenen Teammitglied oder von zwei oder mehr Entwicklern vorgenommen wird zusammen.
Für Zeitschätzungen empfehle ich das Buch „Waltzing With Bears“ von Tom DeMarco und Timothy Lister. Es ist nicht zu lang und macht Spaß zu lesen und wird Ihnen eine verbesserte Methode der Zeitschätzung (optimistisch - realistisch - pessimistisch) beibringen, bei der Sie die gewünschte Zuverlässigkeit einstellen können.
Sprechen Sie auch mit T, aber mehr, um seine Absichten zu erfahren, warum er das alleine mit dem CEO gemacht hat. Will er Teil des Teams werden? Ich denke, seine Aktion wird ihn das Vertrauen des CEO und des restlichen Teams gekostet haben. Hatte er vorher an dieses Risiko gedacht? Ist er nur ein Arschloch und will der glänzende Star der Firma sein? Will er Ihre Hauptrolle übernehmen?
Sie sollten ihm all diese Fragen nicht direkt stellen, aber ich hoffe, Sie haben genug Intuition, um es herauszufinden.
Tob