Ich bin ein beratender Manager, der über 25 Mitarbeiter leitet, um die Infrastruktur auf einem Marinestützpunkt zu verwalten. Das Team ist derzeit in Scrum-Teams unterteilt mit:
- 5 SW-Entwickler, die Fehler beheben und Apps neu schreiben
- 2-3 Cyber-Sicherheitspersonal
- 8–9 Systemadministratoren, die IT-Aufgaben ausführen und neue Apps installieren
- 4 Mitarbeiter für Netzwerkadministration, Debugging und neue Apps und
- 5-6 Bereitstellung von Helpdesk-Personal der Ebene 2, das Eingaben bearbeitet und System-Upgrades durchführt.
Als Regierungsauftragnehmer sind viele der Scrum-Artefakte und -Methoden nützlich für die Nachhaltigkeitsbemühungen, die sich gut für Kanban eignen. Jedes Team verwendet ein Product Backlog, eine wöchentliche Sprintplanung und Kundendemos. Ich setze die wöchentlichen Demos durch, obwohl die meisten Teams unvollständige Produkte haben, um sicherzustellen, dass jedes Team wöchentliche Verpflichtungen eingeht und wir wöchentliches Kundenfeedback erhalten.
Vielleicht würden Kanban-Boards an den Wänden oder in JIRA für ausreichend Transparenz und Verbindlichkeit sorgen. Ich würde mich über Rückmeldungen von Leuten in einer ähnlichen IT-Support-Situation freuen. Ich bin vielleicht zu sehr ein Mikromanager.
Hochachtungsvoll, Gregor
Nachdem ich Ihre Frage und den Kommentar von Tiago Cardoso gelesen habe, gehe ich davon aus, dass Ihr Problem nicht darin besteht, wie wir unsere Organisation strukturieren und agile Teams in einem Kontext mit mehreren gleichzeitigen Projekten definieren können. da Sie auch eine bestimmte Struktur haben und die Dinge gut zu funktionieren scheinen.
Stattdessen suchen Sie nach Anleitungen, um die Kontrolle über das Projekt zu behalten (und die Produktivität zu steigern) und dies den Stakeholdern mitteilen zu können. Um dieses Gefühl der Eigenverantwortung zu schaffen, schlage ich zwei Dinge vor
Verwenden Sie ein Kanban-Board, ein Tool zur Organisation von Work in Progress (WIP). Die Arbeit wird auf Karten, Post-its, Schildern oder Magneten dargestellt. Jedes dieser Objekte repräsentiert eine funktionierende Komponente. Objekte werden dann in Listen organisiert, die den Produktionsprozess oder die Produktentwicklung darstellen. Ein Beispiel für das Organisieren von Listen ist „Nicht begonnen“, „In Bearbeitung“ und „Abgeschlossen“. Dies ermöglicht Transparenz über die Arbeit und den Arbeitsfortschritt und hilft jedem Teammitglied, sich für das Ganze verantwortlich zu fühlen.
Wenn Sie eine Anwendung erstellen und eine Versionskontrolle wie Git verwenden, können Sie den Inhalt aus dem Master-Branch an einem privaten Ort platzieren, damit sie ihn sehen können. Jedes Mal, wenn der Zweig aktualisiert wird, aktualisieren Sie, was dieser Inhaltsspeicherort hat. Wenn es sich um eine Webanwendung handelt, können Sie ihnen auch eine Liste von Benutzern mit unterschiedlichen Berechtigungen für den Fall zur Verfügung stellen, dass sie sich selbst testen oder ihren Lieben zeigen möchten (was meiner Meinung nach häufig der Fall ist).
In einigen meiner Projekte hatte ich immer mit wöchentlichen Sprints zu kämpfen. Wenn sie nicht genau geplant sind, bleibt das Team auf dem Trockenen. Wöchentliche Sprints lassen sehr wenig Zeit für die Risikominderung. Die Wahrscheinlichkeit, dass wöchentliche Sprints Sprintziele verfehlen, ist hoch. Was ich als hilfreich empfunden habe, sind wöchentliche Kundenmeetings, um die Erwartungen an die Kundendemo festzulegen (nicht länger als 20 Minuten), wobei zweiwöchentliche Sprints mit einer Kundendemo enden, die den zuvor festgelegten Erwartungen entspricht.
Es ist immer gut, den Kunden in das Jira-Board aufzunehmen, das stellt sicher, dass das Team 100 Prozent gibt.
Ich persönlich bevorzuge KANBAN für Wartungs- und Versorgungsprojekte.
nvoigt
Gregor Goodwin
Tiago Cardoso
MCW