Mein Team besteht aus 4 Personen
Überblick:
Die Agentur, für die ich arbeite, besteht aus 7 Abteilungen. Meine Abteilung (Data Services) ist verantwortlich für die Datenerfassung, Dateneingabe, Neuentwicklung und Wartung bestehender Webanwendungen (insgesamt 5 Websites, einschließlich Salesforce für 70 Benutzer). Ich bin derzeit der Einzige, der alle Websites einschließlich Salesforce entwickelt, pflegt und verwaltet. Ich bin auch derjenige, der für alle meine Mitarbeiter verantwortlich ist und kann jedes Team zusammenstellen, das ich brauche, aber mit nur den Ressourcen, um 3 Mitarbeiter einzustellen.
Warum ich Scrum verwenden möchte:
Ich möchte ein Scrum-Team zusammenstellen, weil sich unsere Projekte oft und zufällig aufgrund der Politik ändern. Beim traditionellen Management stellte ich also fest, dass ich neu anfing und viel Zeit damit verschwendete, Anforderungen neu zu schreiben, nur um sie mitten in der Entwicklung zu ändern.
Mein Problem:
Kann ich mit den oben aufgeführten Ressourcen erfolgreich ein Scrum-Team aufbauen? Der Grund, warum ich mir Sorgen mache, ist, dass ich derjenige bin, der die Rolle des Scrum Masters sowie die Salesforce-Entwicklung, die .NET-Entwicklung und die Verwaltung meiner Mitarbeiter unter einen Hut bringt. Zugegeben, ich werde einen Junior-Entwickler und einen stellvertretenden Salesforce-Administrator haben, das wird einige Zeit dauern, um sie auf den neuesten Stand zu bringen.
Ist dies also, um es zusammenzufassen, möglich, ohne die konzeptionelle Kontrolle zu gefährden? Was ich damit meine ist; mit den Arten von Ressourcen und nicht dediziertem Scrum Master (da ich auch ein paar andere Rollen habe) habe ich ein hohes Risiko für einen Fehler bei der Verwendung von Scrum?
In Ihrer Situation würde ich dringend empfehlen, Entwickler einzustellen, die bereits in einer Scrum-Umgebung gearbeitet haben, damit sie nicht so viel Coaching von Ihnen benötigen. Sie müssen keine CSMs oder ähnliches sein, aber sie sollten das Framework verstehen und mit einem Team gearbeitet haben, das es zuvor verwendet hat. Je weniger Händchenhalten Sie mit ihnen im Prozess zu tun haben, desto besser. Für das Vorstellungsgespräch würde ich sie einfach bitten, Ihnen einige der Vor- und Nachteile von Scrum oder agiler Entwicklung zu erzählen, die sie miterlebt haben. Sie sollten in der Lage sein, innerhalb von ein oder zwei Minuten zu sagen, ob sie die Erfahrung haben, und auch eine Vorstellung davon bekommen, wie gut sie mit dem System arbeiten werden.
Achten Sie auch darauf, dass Scrum Sie nicht einschränkt. Bei einem kleinen Team stellen Sie möglicherweise fest, dass ein Teil von Scrum für Ihr Team übertrieben ist. Als Beispiel sehen Sie möglicherweise bestimmte Dauern, die für das Timeboxing Ihrer Meetings aufgelistet sind. Während ein 12-köpfiges Team durchaus 4 Stunden Planung für einen 2-wöchigen Sprint benötigen kann, stellen Sie möglicherweise fest, dass Ihr 4-köpfiges Team 2 Wochen in einer Stunde planen kann. Denken Sie immer daran, das zu tun, was für Ihr Team/Projekt sinnvoll ist, und nutzen Sie Ihre Retrospektiven, um dies zu erleichtern.
Ihre Teamgröße/-zusammensetzung ist in Ordnung. Ich habe Scrum schon früher persönlich bei Projekten eingesetzt, bei denen ich das einzige Teammitglied war. Ich habe auch an Projekten gearbeitet, bei denen ich Teammitglied, Scrum Master und Product Owner war. Es ist keineswegs ideal, aber manchmal lassen Ihnen die Einschränkungen der realen Welt keine andere Wahl. Es kann aber funktionieren. Eine wichtige Sache ist, immer sicherzustellen, dass das Team weiß, in welcher Rolle Sie zu einem bestimmten Zeitpunkt sprechen. Sie müssen ihnen versichern, dass Ihr Status als Chef keine Rolle spielt, wenn Sie als Teammitglied arbeiten. Sie werden es schwer haben, ein sich selbst verwaltendes Team zu erreichen, wenn Sie dies nicht tun, weil sie Sie immer als ihren Chef ansehen werden, um ihnen Marschbefehle zu geben, und das wird nur mehr von Ihrer ohnehin begrenzten Zeit in Anspruch nehmen.
Der Erfolg eines Scrum-Teams hängt stark vom Product Owner und seiner Arbeit ab. Wenn es ihr nicht gelingt, ein gutes und brauchbares Product Backlog zusammenzustellen, spielt es keine Rolle, wie gut das Scrum-Team ist, es wird scheitern. Wenn Sie noch keinen Product Owner haben, besorgen Sie sich einen. Denken Sie daran, dass der Product Owner kein Mitglied des Scrum-Teams ist und auch keins sein kann, da er das Backlog aktuell und gültig halten muss, was nicht wirklich Zeit für die Entwicklung lässt.
Die nächste Schlüsselfigur ist der Scrum Master. Ihr Team ist ziemlich klein und es besteht eine gute Chance, dass Sie mit einem engagierten Scrum Master Fortschritte machen können, aber es ist wichtig, etwas Zeit zu sparen, um mehr über Scrum zu lernen und häufige Diskussionen innerhalb dieses Teams darüber zu führen, wie Scrum richtig durchgeführt wird. Es muss eine Recherche + Präsentation + Gespräch wie eine Diskussion sein.
Ich habe gelesen, dass sich das Projekt oft ändert. Wie oft? Denn wenn es sich wöchentlich ändert, kann es zu Problemen mit Scrum kommen. Eine traditionelle zweiwöchige Iteration kann in diesem Fall zu lang sein. Wie auch immer, Scrum ist ein guter Anfang – wenn Sie den engagierten Product Owner und das Backlog haben –, aber ich würde meine Meinung zu den jüngsten Ereignissen über die kontinuierliche Bereitstellungsbewegung behalten.
Welt von Chris
vierq