Aus Effizienzgründen haben wir in unserem Prozess das unverbindliche Erstgespräch eingeführt. Hier haben wir die Möglichkeit den potentiellen Neukunden besser kennenzulernen und umgekehrt, der Kunde bekommt auch einen besseren Eindruck von uns. Neben dem Kennenlernen geht es im Erstgespräch in erster Linie um die korrekte Aufnahme der Kundenwünsche. Dies geschieht in der Regel mit einem passenden Formular, welches sicherstellt, dass zur Erledigung des Kundenanliegens weiträumig an alles gedacht wird. Bei sehr individuellen bzw. großen Projekten bekommt man die Anforderungen oft nicht in Formularen untergebracht. Hierfür gibt es aber zum Glück genügend Ausweichmöglichkeiten. Da wir bei blankid stets bemüht sind agil zu arbeiten (auch wenn nicht jeder Kunde diese Prozesse im Hintergrund tatsächlich mitbekommt), verstehen wir das Erstgespräch als Jagd nach Aufgaben für den späteren Backlog. Sollte es an dieser Stelle zur Entscheidung kommen, dass eine Zusammenarbeit nicht sinnvoll wäre, kann die Jagd auch wieder beendet werden, ohne das sie viel Aufwand verursacht hat.

Im Backlog werden die einzelnen Aufgaben festgehalten. Der Umfang hängt dabei in der Regel stark von den individuellen Kundenwünschen ab. Regelmäßig leiten wir die aus dem Erstgespräch gewonnene Erkenntnisse ab und erstellen entsprechende Aufgaben. Diese werden dann im Zuge der Sprintplanung mit dem Kunden besprochen und ggf. ergänzt oder verändert. Der Backlog kann jederzeit mit neuen Aufgaben/ Anforderungen gefüllt werden. Allerdings muss einen Aufgabe im Rahmen des Sprint- Planungsmeeting erst in den Sprint- Backlog aufgenommen werden, um berücksichtigt zu werden.

Das Sprint- Planungsmeeting (auch “Sprint planning” genannt) wird in der Regel digital per Videochat durchgeführt. Heutzutage müssen wir nur selten zum Kunden rausfahren um die Arbeitsergebnisse zu besprechen. Aus ökologischer Sicht ist das super und auch arbeitstechnisch spart dies enorm viel Zeit, die wir besser in Kundenprojekte investieren, als im Stau zu stehen. Beim Sprint- Planungsmeeting besprechen wir gemeinsam mit dem Kunden die Aufgaben, die wir im kommenden Short Term Sprint umsetzen sollen. Dabei stehen wir dem Kunden beratend zur Seite und klären zusammenhängende Aufgaben. Aus Erfahrung können wir meistens aus der Best Practice eine sinnvolle Reihenfolge für die zu erledigenden Aufgaben empfehlen.

Im Sprint BackLog werden die im Sprint- Planungsmeeting definierten Aufgaben festgehalten. Nach dem Start eines Short Term Sprints können keine weiteren Aufgaben mehr nachträglich hinzugefügt werden. Das Div-Team erledigt die Aufgaben eigenverantwortlich und stellt die Ergebnisse in der Sprint- Retrospektive vor.

In einem Scrum Entwicklungsteam, auch Development Team (Dev.-Team) genannt, finden sich alle Teilnehmer wieder, die mit Ihren Fähigkeiten zur Entwicklung des Vorhabens beitragen können. So sind dies regelmäßig professionelle Grafikdesigner, FrontEnd-/ und BackEnd- Entwickler, IT- Security Officer, Datenschutzreferenten, Texter, Layouter, Projektmanager oder sonstige Projektteilnehmer. Dabei bleibt ein zusammengestelltes Entwicklungsteam meistens für die Dauer des gesamten Projektes zusammen. Dies hat den Hintergrund, dass die Dev.Team- Mitglieder sich im Projekt aufeinander einspielen und die Zusammenarbeit mit der Zeit immer effizienter wird. Darüber hinaus können situativ und außerhalb eines laufenden Sprints weitere Projektteilnehmer mit benötigten Spezialfähigkeiten konsultiert werden.

In den Alltag einer gesunden Agentur gehört ein kontinuierlicher Strom an Aufgaben. Dieser sollte sich aus einer guten Mischung an Bestands-, Neukundengeschäft und Agenturinternen Aufgaben zusammenstellen. Sicherlich gibt es verschiedenste Wege diese Aufgaben in geordneter und reportingfähiger ??????? Weise zu managen. Wir haben uns dabei für Scrum entschieden.

Er hat Kapazität für bis zu 4 externen und einem internen Short Term Sprint. Maximal kann ein Long Term Sprint also 5 einzelnen Short Term Sprints beinhalten. Sollten kurzfristig mehr Short Term Sprints benötigt werden, besteht die Möglichkeit ein weiteres Dev.Team aus unserem Agenturnetzwerk zusammenzustellen und einen zusätzlichen Long Term Sprint zu eröffnen. So halten wir unsere Entwicklungskapazitäten fortlaufend flexibel. Abweichend vom üblichen Vorgehen bei Scrum- Projekten halten wir unsere Long Term Sprints offen, d.h. ein Long Term Sprint kann bspw. mit 3 Short Term Sprints starten und wir können während des Sprints weitere Short Term Sprints (sinngemäß zusätzliche Sprint Aufgaben) bis zur maximalen Anzahl von 5 Stück hinzufügen.

Ein Short Term Sprint repräsentiert entweder externe durch unsere Kunden generierte oder agenturinterne Aufgaben. Pro Short Term Sprint gilt als Faustformel, dass 20% der Arbeitskapazität eines Dev.Teams pro Woche verplant werden kann. Dies ergibt sich aus der maximalen Anzahl an Short Term Sprints in einem Long Term Sprint. Die Short Term Sprints folgen jeweils den üblichen Scrumregeln und werden im Vorfeld über einen Backlog geplant und im Sprint Planning final festgelegt.

In der Sprint Retrospektive besprechen wir mit jedem Kunden einzeln die Ergebnisse des vorangegangenen Short Term Sprints. Im Agenturalltag bezeichnen wir diese Projektstation auch oft als Kundenrevision, welche entweder einen weiteren Short Term Sprint oder den Abnahmeprozess einleitet. Durchgeführt wird die Retrospektive/ Revision genau so wie das Sprint Planungsmeeting.

Weil wir mit Leidernschaft dabei sind, führen wir nach der Sprint- Retrospektive mit dem Kunden nochmal einen interne Sprint- Review durch, um unsere Prozesse und Arbeitsabläufe kontinuierlich zu verbessern.

Führen wir Projektabhängig durch.

Für die Organisation und Abbildung unserer Arbeit nutzen wir branchenübergreifend bekannte Software-Produkte marktführender Anbieter. Ab einer sinnvollen Projektgröße, separieren wir die Aufgaben des Auftraggebers in einer eigenen Projektumgebung. Hier können wir dann von unserer normalen Vorgehensweise abweichen und bspw. andere Sprintabläufe, Aufgabentypen oder Zeit Intervalle bestimmen und die Zusammenarbeit mit unseren Kunden an die jeweiligen Bedürfnisse anpassen.

Abhängig von den Projektanforderungen des Kunden, ergänzen wir unsere agilen Abläufe, um verschiede Projektmanagement Methoden. So arbeiten wir fast immer mit Kanban- Boards , erstellen für längere Projekte detaillierte Roadmaps und führen unsere Projekte stets nach der Lead Philosophie (wir legen Wert darauf, keine Ressourcen zu verschwenden) durch. Werden die Anforderungen spezifischer, so können wir auf Kundenwunsch noch speziellere Methoden ergänzen.

Aus der Agilität heraus bietet sich regelmäßig die variable Vergütung an, also die Entlohnung nach unserem Stunden und Tagessatz. Dennoch gibt es einige Projekte die einem sehr ähnlichen Schema folgen, bei denen wir in der Lage sind entsprechende Fixpreise anzubieten. Am Ende hängt es also oft mit dem Vorhaben des Kunden und den den spezifischen Wünschen zusammen.