Agile mit Super Powers

Superboys: Edict-Abhilekh on Pixabay

tl;dr Scrum Rollen superpowern: Es gibt viel zu tun. Deshalb muss man Fähigkeiten zusammenlegen: Scrum-Master coacht auch agile Technologien, Product Owner macht UX-Design, Visual-Designer kann Frontend-Programmierung, Entwicklungsleiter ist Technik-Coach für Product Owner.

In der realen Welt haben wir mehr Rollen, als die bekannten Scrum-Rollen: Scrum Master, Product Owner und Entwicklerin.

Außerdem gibt's da noch:

• Tester, die Test-Ingenieure sein sollten, nicht Durchklicker, sondern Integration-Test-Entwickler und Test-System Managerinnen,  
• Admins, früher Operator, jetzt Devops, also Devs mit Leidenschaft für Betrieb, 
• Systemarchitektinnen, die sich oft aus den Entwicklern rekrutieren und auf jeden Fall aktiv in den Entwicklungsteam sein sollten, vielleicht organisiert in Communities of Practice, aka Chapters, 
• UX-Designer, ständig ein bisschen gebraucht, denn bei jedem Feature mit Business-Value für Benutzerinnen ist UX wichtig, 
• Visual-Designer, soll ja auch gut aussehen, oft zwischen mehreren Teams geteilt oder sogar extern bei einer Agentur oder beim Auftraggeber. Burst-artige Arbeitslast und deshalb immer in der Gefahr, die Entwicklung aufzuhalten. 
• Produkt Managerin, die auch gewillt ist mit dem Agile-Team ins Eingemachte zu gehen und zusammen was umzusetzen. Phantastisch, wenn sie nicht aufhört bei Marktpotential/Marktbeobachtung und Anforderungen, sondern selbst die User Stories scheibt. 
• Marketing, Vertrieb, Controlling, Management… sind auch nötig, damit was geht, schon klar.

Von den Entwicklerinnen verlangt man heute viele Fähigkeiten:

• Frontend und Backend, jeweils mit ihren aktuellen (und schnell wechselnden) Frameworks, 
• Unit Tests ohne Zeit-Overhead während des Codings "einfließen" zu lassen, 
• Integration-Tests und GUI-Tests aufzusetzen und up-to date zu halten während sich UX Workflows ändern, 
• Beherrschung von Continuous Integration/Deployment Systemen, 
• Container und Orchestrierung, 
• Virtuose Bedienung von Code Repositories für Quellcode, Pakete, Container (Stichworte: GitFlow, nuget/PEAR, Dockerhub). Nicht nur benutzen, sondern auch bereitstellen, intern und extern. 
• Code Reviews und Refactoring
• Code-Metriken
• Kenntnis und Benutzung von Monitoring-Systemen für Alarm, Dashboard und KPIs, 
• Clean Code, Design Patterns, Entwicklungsumgebungen und deren Extensions, 
• Security (in Code, Libraries aus Repos?, Operating), 
• Reliability-Engineering, 
• Skalierung (Up and Out)
• Konfiguration der APIs und GUIs diverser Cloud-Anbieter und Meta-Cloud-Services, 

usw.

Unter den Entwicklern gibt es Spezialisten für das alles. Aber nehmen wir ein Team von 7, (UX-) Designer, Tester, Admin (ähm, Devops), Frontendler, Backenderin. Eigentlich sollen alle alles können, aber nicht jede, die Microservices containerisiert ist gleichzeitig ein CSS3-Wizard. Dann wird es langsam eng mit den oben genannten Spezialfertigkeiten. Coden sollen sie ja auch noch. 

Warum machen wir das alles?

Damit Features entstehen. Features, die User glücklich machen. Features entstehen durch Coding. Ohne Coding keine Features. Viel Coding - viele Features, wenn sonst alles stimmt.

Fragt man in der Retro "was hat dich in diesem Sprint vom Coden abgehalten?" - typische Antwort: "Meetings", aber auch immer öfter "Infrastruktur" und vor allem: Infrastruktur aneignen, neu lernen und verstehen. 

Ganz viel dieser Infrastruktur macht uns agil bzw. ist nötig für agile Arbeitsweise über Scrum/Kanban hinaus:  Continuous-*, Container, Cloud, Clean Code, Frameworks, Repositories…

Die Infrastruktur hat gemeinsam: Sie ist aufwändig für jede einzeln zu lernen, aber notwendig, und wenn erstmal gelernt, dann völlig OK. Aber bis dahin dauert es.

Man kann das nicht alles den Entwicklern aufbürden, deshalb verteilen wir das:

Superpower #1: Agile-Coach mit agiler Technologie

Es könnte/sollte/müsste die Aufgabe des Scrum-Masters sein, agile Technologien in das Team zu tragen, so wie auch agile Arbeitsweisen in das Team getragen werden. Natürlich soll die Scrum-Masterin nicht dauerhaft den Build-Server betreuen (obwohl sie das kann, wenn sie mehrere Hüte aufhaben will/kann/soll). Es geht darum, dass der Agile-Coach das Wissen in das Team trägt, damit nicht immer wieder wertvolle Entwicklerzeit darauf verwendet wird, zu lernen, wie man einen KPI-gesteuerten Continuous Deploment Prozess konfiguriert. Und wenn wir schon dabei sind: Es ist auch die Aufgabe des Agile-Coaches, die Beschäftigung mit Clean-Code und Design-Patterns zu stimulieren, vielleicht sogar selbst zu schulen, zumindest aber die Seniors dazu zu bringen, dass sie ihr Wissen teilen. Aber dazu muss man wissen, was es zu teilen gibt. Sorry, liebe SMs aus dem Persönlichkeitscoaching, eine agil-technische Scrum Masterin macht das Team nicht nur glücklicher, sondern auch schneller, viel schneller. Und mit "schnell" kommt dann auch "glücklich": Superpowered Scrum-Master.

Superpower #2: Product Owner mit UX-Design

Bei allen Features mit Business-Value für Endbenutzer ist UX wichtig. Coding ist dafür da, dass die Funktion funktioniert. Aber "glücklich" werden Benutzer durch gutes UX-Design, nicht nur schöne GUIs, sondern vor allem gute Workflows. Ein Product Owner gießt die Stakeholder-Anforderungen in User Stories. Bei fast jeder Story ist UX-Design nötig, zumindest Grundkenntnisse, besser umfassende. Eine gute UX-Designerin kann lernen, wie man User Stories schreibt und vielleicht sogar wie man mit Stakeholdern redet. Aber ob ein Product Owner UX lernt? UX-Design ist ein Beruf und gottgleiches User-Story Schreiben eine Berufung. Erst die klassische Ausbildung: gute Anwendungen entwerfen, dann die agile Spezialfähigkeit: User Stories und Kommunikation: Superpowered Product Owner.

...und weil wir schon dabei sind. Das wäre auch toll:

Superpower #3: Visual-Designer mit Frontend-Programmierung

Wenn die Visual-Designerin gut ist, wird die Anwendung schön. Wenn sie das, was designed wurde, auch umsetzen kann, ist es toll für alle. Denn dann muss sie das Design nicht an den Entwickler übergeben. Es gibt keine Rückfragen, keine Verzögerung, keinen Mind-Bruch. Sie kann beim Design gleich die technischen Randbedingungen berücksichtigen. Keiner muss der CSS-Sklave für die Designerin sein. Die Arbeitslast ist viel ausgeglichener, so dass man kann sich eine ganze Designerin exklusiv pro Team leisten jund nicht mehr UX-Designer zwischen Teams teilen muss: Superpowered Designer.

Superpower #4: Entwicklungsleiter mit Technik-Coach für Product Owner

Viele Product Owner kommen nicht aus dem technischen Bereich. Das ist gut so, um die Entwicklung mit dem Produktmanagement zu verzahnen. Auf der anderen Seite ist es von Vorteil, wenn die User Stories so geschrieben werden, dass sie 1. in die Gesamtarchitektur passen und 2. die Entwickler verstehen und machen, was gemeint war. Für beide Fälle ist es gut, wenn jemand aus der Technik den Product Owner bei der Formulierung der User Stories berät. Eigentlich sind die Entwicklerinnen die technischen Berater des Product Owners. Aber das kostet Entwicklerzeit, oft von allen. Deshalb bürden wir das lieber der Entwicklungsleiterin auf. Die Entwicklungsleiterin kennt die Gesamtarchitektur, die IT-Strategie und sie versteht wie Entwickler denken. Sie schreibt nicht die Stories um. Nur der PO schreibt User Stories. Aber eine Entwicklungsleiterin kann durch Fragen den Product Owner dazu bringen, die Stories so zu schreiben, dass die Entwickler die Stories verstehen und dass sie in das Gesamtkonzept passen. Eine Stunde pro Woche und Team reicht, um die technische Qualität der User Stories deutlich zu verbessern. Die Entwicklungsleiterin kann so wissen was passiert und gleichzeitig etwas steuern. Die Stunde pro Woche mit dem PO ist das effizienteste Steuerungswerkzeug der agilen Entwicklungsleiterin, ohne den agilen Prozess zu verletzen. 

Heute sind viel mehr Fertigkeiten nötig. Man muss Fähigkeiten zusammenlegen. Nicht nur bei den Entwicklern, denn die sollen entwickeln. Alle müssen mehr machen und mehr können als bisher. 

Niemand hat gesagt, dass Superkräfte einfach sind.

#SuperPoweredAgile

_happy_powering()