Kopf frei halten und mitdenken:

Kopf frei halten: Fokus durch Kanban und begrenzte parallele Arbeit

Wir organisieren uns in allen IT-Bereichen nach Kanban, so auch in der Softwareentwicklung. Das Thema Kanban selbst möchte ich hier allerdings nur kurz anschneiden, da die generelle Ausrichtung der Arbeitsphilosophie bereits vorgegeben ist. Kanban definiert vier Grundprinzipien und sechs Kernpraktiken, unter anderem „Limitiere die Menge paralleler Arbeit”. Jeder, der sich kurz mit Kanban beschäftigt hat, kennt „Work-In-Progress-Limits” oder das „Pull-Prinzip” .

Welche Philosophie steckt nun dahinter? Jedem Mitarbeiter soll die Möglichkeit geboten werden, begonnene Arbeit qualitativ gut fertigzustellen. Bevor neue Arbeit begonnen wird, muss der eigene Arbeitsbereich frei von offenen To-Dos sein.

Durch die Limitierung paralleler Arbeit und der Regel, dass neue Arbeit aktiv eingefordert werden muss, hat jeder Mitarbeiter eine überschaubare Menge an Aufgaben in seinem eigenen Verantwortungsbereich liegen. Dieser Grundgedanke, die Arbeitsmenge immer möglichst überschaubar zu halten, zieht sich wie ein roter Faden durch die Tätigkeiten und Aufgabengebiete der Entwickler. In IT-Berufen, gerade in der Softwareentwicklung, ist es enorm wichtig, begonnene Arbeit zu beenden und größere Ideenstapel zu vermeiden, um den Fokus auf das aktuelle Ziel nicht zu verlieren.

Dieser Grundgedanke beschreibt sehr gut, worauf wir unseren Fokus legen: Qualität. Qualität geht bei uns immer vor Geschwindigkeit oder Quantität.

Projekt organisieren: Große Entwicklungsprojekte in kleine Arbeitspakete teilen

Beginnt ein Entwickler ein Projekt, legt er sich nach der technischen Planung selbst Teilaufgaben an. Das große Projekt soll in so viele einzelne Bausteine wie möglich unterteilt werden. Jeder einzelne Baustein für sich bildet wieder ein überschaubares Arbeitspaket.

Kleine Commits für bessere Code-Reviews

Für Commits gilt die Grundregel, dass maximal zehn Dateien gleichzeitig committed werden dürfen. Ziel hiervon ist, ein Changeset möglichst übersichtlich zu halten. Changesets werden von anderen Entwicklern gereviewed. Auch hier gilt: Je übersichtlicher das Changeset, desto effizienter das Code-Review.

Zusätzlich soll so erreicht werden, dass durchgeführte Änderungen möglichst schnell wieder committed werden und der eigene Arbeitsplatz (in diesem Fall der ausgecheckte Code) wieder einen sauberen Stand ohne lokale Änderungen hat. Auch hier soll kein Ballast mitgeschleppt werden.

Clean-Desk für freie Gedanken

Wir verfolgen eine Clean-Desk-Policy. Der Schreibtisch, zu dem auch Schubladen oder Schrankfächer gehören, soll zum Feierabend immer aufgeräumt und möglichst leer sein. Clean-Desk-Policies haben viele Vorteile, von denen ich einen besonders hervorheben möchte. Um jeden Abend einen sauberen Schreibtisch verlassen zu können, muss ich meine Arbeitsorganisation auf dieses Ziel hin ausrichten. So kann ich keine Notizen auf Zetteln zu machen und sie auf verschiedenen Stapeln oder in Schubladen organisieren. Ich zwinge mich selbst dazu zu entscheiden, was ich mit einer Idee, einer Notiz oder einem To-Do mache. Übernehme ich es als Aufgabe in die Software und treffe damit die Entscheidung, mich aktiv damit zu beschäftigen? Oder entsorge ich die Idee in Papierform und damit vorerst auch aus meinem Kopf und widme mich wieder wichtigeren Dingen?

Mitdenken: Eigenverantwortung und Leadership in IT-Teams

Ein weiteres Kanban-Grundprinzip ist „Ermutige dazu, Führung auf jeder Ebene des Unternehmens zu zeigen”. Mit dem Begriff „Führung” (englisch: Leadership) ist hier die Förderung unternehmerischen Denkens gemeint. Egal wie gut ein Controlling ist, egal wie gut die Führungskräfte sind, nichts davon ersetzt einen unternehmerisch denkenden Mitarbeiter. Ein mitdenkender Mitarbeiter erkennt unnötige Arbeit oder falsch eingeschlagene Wege schon in dem Moment, in dem sie auftreten. Ein eingerichtetes Controlling erkennt dies erst danach.

Teams

Die Entwicklungsabteilung ist in mehrere Teams aufgeteilt, die sich möglichst selbst organisieren. Es gibt Teams für konkrete Projekte, aber auch allgemeine Teams.

Projektteams

Projektteams werden gebildet, wenn ein Modul oder ein größeres Feature entwickelt werden soll, an dem mehrere Entwickler über einen längeren Zeitraum arbeiten. Jedes Projektteam wird von einem Produktmanager betreut und plant und setzt das Feature in Teilen um.

enterprise

Das enterprise-Team führt allgemeine Anpassungen an der CRM-Software durch und bietet uns die Möglichkeit, auch außerhalb der großen Weiterentwicklungsprojekte flexibel Anpassungen in verschiedenen Bereichen umzusetzen.

Tec

Unser Tec-Team ist für die technische Weiterentwicklung unserer Software verantwortlich. Neben klassischem Refactoring wird hier auch die technische Basis der einzelnen Tools stetig weiterentwickelt.

Operation

Das Operation-Team ist für den Betrieb und die Auslieferung der Software verantwortlich. Neben Uploads und Releases werden hier auch zeitkritische Bugfixes durchgeführt. Die Überwachung der Unit-Tests und weitere Qualitätsüberwachungen fallen ebenfalls in den Aufgabenbereich dieses Teams.

QA

Das QA-Team führt Abnahmetests zu durchgeführten Änderungen durch, bespricht sie zusammen mit den umsetzenden Entwicklern und pflegt auch unsere Onlinehilfe.

Fazit

Viele kleine Bausteine der Teamorganisation forcieren ein Mitdenken. QA-Manager und Entwickler entscheiden zusammen, welche Fehler noch behoben werden müssen und welche nicht. Teams, die mit dem Produktmanagement zusammenarbeiten, erhalten die erstellten Anforderungsdokumente zur Prüfung und können so Einfluss auf geplante Funktionen nehmen, bevor sie in die Umsetzung gehen. Die Liste kann beliebig fortgesetzt werden.