Dienstag, 24. März 2015

Staatliche Förderung für Scrum-Zertifizierungen

Was man alles so lernt. Agile Zertifizierungen jeglicher Art (Scrum Alliance, Scrum.Org, ISTQB, ISQI, PMI) muss man nicht komplett selber bezahlen - der Staat übernimmt die Hälfte der Kosten. Einzige Vorausetzung ist, dass man in einem Unternehmen angestellt sein muss (ggf. ist das das dann eben die eigene GmbH & Co KG). Wenn das gegeben ist, greift die Förderungswürdigkeit durch den Europäischen Sozialfonds (ESF), die dann je nach Bundesland anders umgesetzt wird. Hier in NRW bekommt man so genannte Bildungsschecks ausgestellt, die der Zertifizierungsanbieter bei der jeweiligen "Bewilligungsbehörde" einreichen kann.

Auf der einen Seite spart das natürlich viel Geld (bis zu 2000,- € pro Förderung!), auf der anderen Seite ist es furchtbar bürokratisch. Man muss eine Beratungsstelle finden, die erforderlichen Informationen zusammentragen, Unterlagen vorbereiten, an einem Beratungsgespräch teilnehmen und Formulare ausfüllen. Dazu ist es mit einem weitgehenden Daten-Striptease verbunden. Name, Geschlecht, Beschäftigungsverhältnis, Bildungshistorie, Migrationshintergrund und vieles mehr wird in irgendwelche Datenbanken aufgenommen und nach Brüssel geschickt, wo EU-Beamte mit kritischem Blick untersuchen, ob das Geld denn auch wirklich bei der angedachten Zielgruppe ankommt. Ob man das will muss jeder selbst wissen, umgehen kann man es nicht. Um es in der unnachahmlichen Prosa der deutschen Beamtensprache zu sagen:

Diese Angaben werden benötigt, weil das Land Nordrhein-Westfalen seinerseits für die Mittelvergabe aus dem Europäischen Sozialfonds nach Maßgabe der gemeinsamen Verordnung über die Struktur- und Investitionsfonds (EU) 1303/2013 vom 17.12.2013 bestimmten Berichtspflichten an die Europäische Kommission nachkommen muss. Erfüllt das Land Nordrhein-Westfalen diese Pflichten nicht oder nur ungenügend, drohen dem Land gemäß dieser Verordnung Rückforderungen von bereits zugewiesenen Mitteln.

So weit so amüsant. Mein Kritikpunkt wäre ein anderer: Laut Broschüre des Arbeitsministeriums (nicht online) richtet sich das Programm eigentlich an "Menschen mit Qualifizierungslücken", "Un- und Angelernte", "Beschäftigte ohne Berufsabschluss" und "Zuwanderer, die eine Nachqualifizierung anstreben". Gerade diese werden aber mit der oben genannten Bürokratie völlig überfordert sein. Ich nehme stark an, dass ein großer Teil der Gelder stattdessen bei solchen Unternehmen landen wird, die im Umgang mit Behörden- und Konzernprozessen erfahren sind: bei den Beratungsunternehmen verschiedenster Art. Wobei auf der anderen Seite natürlich auch zu sagen ist, dass keineswegs jedes Beratungsunternehmen im Geld schwimmt, viele werden diese Förderung gut brauchen können. Naja.

Wer sich in die Beantragungsprozesse stürzen möchte, kann das hier tun. Viel Glück.

Montag, 23. März 2015

Warum die Süddeutsche Zeitung Scrum richtig einsetzt

Bild: Wikimedia Comons, Clemens Pfeiffer - CC BY 2.0

Noch vor einigen Jahren hätte ich so etwas "Neumodisches" wie Scrum bei einem Unternehmen wie dem Süddeutschen Verlag nicht erwartet. Ich habe ja meine beruflichen Erfahrungen in der Medienbranche gemacht, und freundlich gesagt - ich hatte häufig den Eindruck, dass die Tradition dort höher geschätzt wird als die Innovation. Für einige Zeitungshäuser stimmt das sicher immer noch, bei der Süddeutschen Zeitung bin ich aber mittlerweile anderer Meinung. Erstmals aufmerksam geworden bin ich vor zwei Jahren, als ich hörte, dass die SZ für ein Scrum-Projekt Testautomatisierer sucht. Seitdem blitzten die Buzzwords Süddeutsche und Scrum immer wieder gemeinsam in meiner Timeline auf und verbanden sich immer mehr zu einem Bild. Vorläufiger Höhepunkt: Ein Interview mit und ein Blogeintrag von sz.de-Chefredakteur Stefan Plöchinger veröffentlicht auf horizont.de und in seinem Tumblr-Blog. [Edit: der Blogbeitrag ist mittlerweile gelöscht]

Neben anderen vernünftigen Aussagen (z.B. der, dass digitaler Journalismus interdisziplinäre Teams aus Journalisten und Programmierern braucht) ist mir vor allem im Kopf hängen geblieben, dass hier eine Vorgabe von Scrum idealtypisch umgesetzt wird: nach jedem zwei-Wochen-Sprint soll Software livegehen um sofort sehen zu können, wie sie beim Kunden/Leser ankommt. Wohlgemerkt, es wird nicht der Anspruch erhoben, dass sie livegehen könnte, wenn man denn wollte, nein, sie wird tatsächlich auf das Internet und seine Bewohner losgelassen. Mit Plöchingers Worten aus dem Horizont-Interview:
Alle zwei Wochen [wollen wir] eine neue Version der Seite publizieren, damit wir alle zwei Wochen reagieren können, im Sinne von Scrum und agiler Produktentwicklung – wem diese Worte nichts sagen, der hat meiner Meinung nach ein Problem in der digitalen Welt.
Das ist besonders. Und zwar ganz unabhängig von dem Medien/Zeitungs-Thema. Es ist besonders, weil sich so kurze Release-Zyklen in Deutschland kaum finden lassen. Hier findet sich normalerweise immer noch die aus dem Wasserfall-/V-Modell stammende Idee von Großreleases alle paar Monate. Wenn davon abgewichen wird hat das weitreichende Auswirkungen: nach mehreren Sprints mit halbherzig ausgeführter Qualitätssicherung noch eine Integrationstest- und Bugfixing-Phase dranzuklatschen, das geht dann nicht mehr. Wenn man nach jedem Sprint neue Funktionen livegehen lässt muss die Qualität stimmen. Dann muss es möglich sein, innerhalb kürzester Zeit nicht nur Software-Tests der neuen Komponenten durchzuführen, sondern auch Regressionstests aller bereits bestehenden (nur so kann man sicher sein, dass diese nicht durch Seiteneffekte beschädigt wurden). An dieser Stelle schließt sich übrigens der Kreis zu der oben erwähnten Anstellung von Testautomatisierern. Darüber hinaus sind aber auch nahezu alle anderen Bereiche der (agilen) Software-Produktion betroffen: Zuschnitt der User Stories, Code-Qualität, Dokumentation, etc.

Ob das alles wirklich so klappt ist von aussen natürlich schwer zu sagen, es klingt aber sehr, sehr vielversprechend. Und ich muss gestehen: da wäre ich gerne dabei.

Donnerstag, 19. März 2015

Wo (und warum) der Ruf von Scrum ruiniert ist

Bild: Pixabay / Geralt - Lizenz
Über die wirklich großartige Agile Cologne gestern könnte ich seitenweise schreiben. Stylische Location, nette Leute, interessante Themen, kleine Polemiken, großartige Organisation.

Als eines unter vielen Highlights würde ich die Session zu "Scrum im nicht-agilen Konzernumfeld" hervorheben, da sie sich genau um das Thema gedreht hat mit dem ich die letzten Jahre unterwegs gewesen bin. Die (aus meiner Sicht) zentrale These: In vielen Konzernen ist der Begriff "Scrum" mittlerweile verbrannt und diskreditiert. Die Gründe:
  • (Traditionelle) Konzernstrukturen sind mit agilem Vorgehen häufig inkompatibel. Von Hierarchiedenken und Fingerpointing geprägte Firmenkulturen machen Eigeninitiative und selbstorganisierte Teams nahezu unmöglich.
  • Mit der Zeit haben sich in vielen Konzernen Regelwerke und definierte Prozesse herausgebildet die so umfangreich sind, dass sie innerhalb von 40-Stunden-Wochen nicht mehr befolgbar sind. Um überhaupt arbeitsfähig zu bleiben werden diese Regeln und Prozesse von den Mitarbeitern systematisch unterlaufen und ignoriert. Diese Haltung hat sich oft so verfestigt, dass sie automatisch auch auf Scrum angewandt wird.
  •  Scrum wird in vielen Fällen nur halbherzig, bzw. mit reduziertem Umfang eingeführt (ScumBut). Wenn aber zentrale Bausteine wie z.B. der Scrum Master, das Daily Scrum oder die Retrospektive fehlen, wird die agile Transition scheitern. Es entsteht bei den Teammitgliedern (die Scrum nur so kennengelernt haben) der Eindruck, dass die Methodik gar nicht funktionieren kann.
  • Selbst wenn Scrum korrekt eingeführt wird, wird häufig erwartet, dass die bisherigen Prozesse zusätzlich dazu weitergeführt werden (ScrumAnd). Da diese wie erwähnt bereits für sich genommen zu schwergewichtig sind, wird das Team überlastet. Die Tendenz sich Prozessen zu verweigern und sie zu unterlaufen wird verstärkt.
  •  Dem für die agile Transition notwendigen Kulturwandel wird nicht ausreichend Zeit gegeben. Um Scrum so (oft) zu erklären, dass es verstanden wird, um Verhaltensweisen zu ändern und um den historisch entstandenen Prozess-Wildwuchs zurückzuschneiden sind Monate, wenn nicht sogar Jahre nötig. In der von Quartals- und Jahreszahlen getriebenen Konzernwelt werden Neuerungen aber mitunter schon als gescheitert betrachtet und zurückgenommen wenn sie nicht bereits nach wenigen Monaten Wirkung zeigen.
Zusammengenommen führen diese Faktoren immer wieder dazu, dass die (falsch durchgeführte) Einführung von Scrum die Ausgangssituation nicht verbessert sondern verschlechtert. Wenn dass dann nicht nur einmal sondern mehrfach passiert ist, ist sein Ruf beim Management so ruiniert, dass bereits die bloße Erwähnung des Namens dazu führen kann, dass man des Raumes verwiesen wird. Das muss nicht unbedingt heißen, dass die Methodik für immer gestorben ist - sie kann sehr wohl erneut eingeführt werden, und das vielleicht sogar erfolgreich. Allerdings nicht mehr unter dem Namen Scrum.

Montag, 16. März 2015

Denn sie wissen nicht, wen sie rekrutieren

Bild: Wikimedia Commons/Exodus Cry - CC BY-SA 3.0
Nach fast vier Jahren auf Projekten in Freiburg, München und Hannover kann ich mich zur Zeit über einen eher entspannten Job freuen und mache PMO-Tätigkeiten im Headoffice in Bonn. Zu den hier anfallenden Aufgaben gehört auch die Kontaktpflege zu verschiedenen Personalstellen, Headhuntern und Personalvermittlern, über die wir immer wieder Aufträge akquirieren können. Auffällig dabei ist, dass ich es dabei in erstaunlich vielen Fällen mit Personen zu tun habe, die nur eine rudimentäre Ahnung von den Qualifikationen haben, die zur Besetzung der von ihnen verantworteten Ausschreibungen notwendig sind. Alles was über den bloßen Text der Ausschreibung hinausgeht löst bei einigen dieser Leute Ratlosigkeit aus, zum Teil scheitert es bereits am Fachvokabular. Wie kann das sein?

Einen Anhaltspunkt bekommt man über die Xing- und LinkedIn-Profile der jeweiligen Personen, aus denen sich in den meisten Fällen Rückschlüsse über Studium und Ausbildung ziehen lassen: Es sind die Klassiker aus dem HR-Bereich - Personalmanagement, Psychologie, BWL mit Schwerpunkt Personal, Jura. Bei diesem Hintergrund kann man die oft fehlenden Kenntnisse des IT-Projektmanagements und seiner Erfordernisse nachvollziehen. Wirklich problematisch wird die Situation aber durch die Art, wie diese Wissenslücken gefüllt werden. Um ein wörtliches Zitat zu bringen: "Wir haben die Fachabteilung gebeten, uns alles aufzuschreiben, was wichtig sein könnte." Kann man so machen. Das Ergebnis ist dann allerdings, dass sich plötzlich alle "Nice to Haves" als harte Anforderungen in den Stellenprofilen wiederfinden.

So weit, so problematisch. Wenn diese Situation jetzt dazu führen würde, dass diese Stellen überqualifiziert besetzt werden, dann wäre das ja erstmal OK. Werden sie aber nicht. Stattdessen höre ich gerade von diesen Leuten, dass es nahezu unmöglich wäre "geeignete Kandidaten" zu finden, so dass Positionen z.T. über Monate hinweg nicht besetzt werden könnten. Kein Wunder - wer allen Ernstes nach einen Product Owner sucht, der jahrelange Branchenerfahrung hat, Scrum- und PMP-zertifiziert ist, Erfahrungen in Kanban und XP hat, auch Wasserfall kennt, mehrere Programmiersprachen beherrscht, fließend mehrsprachig ist, auf mehreren Großprojekten war und sowohl im Mobile- als auch im Datenbankbereich Erfahrungen gemacht hat, der wird einfach nicht so schnell fündig werden (wenn überhaupt).

Wenn aber solche Stellenausschreibungen erst mal draußen sind, sind sie nur schwer zu verschlanken, schließlich will man ja "keine Abstriche bei der Qualität machen". Und dass diese Abstriche nicht zu weniger Qualität führen würden lässt sich kaum glaubhaft vermitteln, wenn der Gesprächspartner von der Materie wenig Ahnung hat (siehe oben). Vermutlich wäre es ein lohnendes Geschäftsfeld, gegen Geld passende Stellenbeschreibungen für IT-Projekte zu verfassen. Gerade die, die diese Hilfe am dringendsten bräuchten, werden sie aber nicht annehmen, denn dann würden sie schließlich ihre eigene Existenzberechtigung in Frage stellen. Ein Teufelskreis.


PS:
Unabhängig davon, dass ich das was ich gerade geschrieben habe für ein Riesenproblem halte - natürlich gibt es viele fähige und erfahrene Personaler, die sehr gute Arbeit abliefern. Aber es sind viele. Nicht alle.

Donnerstag, 12. März 2015

Übergreifende Teamsteuerung mit Kanban-Boards

Bild: Pixabay / Geralt - Lizenz
Die bloße Menge an Agile-, Lean-, Kanban- und Scrum-Veranstaltungen im Raum Köln-Bonn ist erstaunlich. Gestern bei der Limited WIP Society Cologne waren Bücher das Thema. Jeder Teilnehmer war eingeladen eines mitzubringen und vorzustellen. Meines war Lean from the Trenches von Henrik Kniberg, in dem ein agiles Projekt der schwedischen Polizei beschrieben wird. Es gehörte seinerzeit zu den ersten Werken zum Thema Scrum etc. die ich gelesen habe, und tatsächlich habe ich einiges daraus in meine Arbeit übernehmen können. Das Board über das wir in meinem ersten Großprojekt die teamübergreifende Qualitätssicherung gemacht haben geht z.B. ganz wesentlich auf Knibergs Anregungen zurück:


Zu erkennen ist der typische Kanban-Flow: Spalte 1 entspricht den hoch priorisierten Backlog Items, Spalte 2 zeigt die Stories des laufenden Sprints in denen noch gecoded wird, in Spalte 3 hängen die Stories in denen aktuell Akzeptanztests durchgeführt werden, Spalte 4 enthält die Stories die zur Abnahme durch die POs anstehen. Spalte 5 bildet den Übergang zur übergreifenden Qualitätssicherung: Die Tester der jeweiligen Scrumteams stellen die Stories und Tests den anderen Testern vor. In Spalte 6 hängen die Stories deren Tests gerade automatisiert werden (oder in bestehende automatisierte Tests eingearbeitet werden). Spalte 7 war wesentlich größer als hier gezeigt und bildete praktisch das Archiv.

Der Vorteil an diesem Vorgehen: Es entsteht ein großes Bild, das die gesamte Stecke zwischen den Team-Backlogs und den Regressionstest-Suiten zeigt, allen an der Qualitätssicherung beteiligten Personen ist immer bewusst woran die jeweils anderen arbeiten, Aufwände können visualisiert und gesteuert werden, es findet ein Wissenstransfer zwischen den Teams statt. Der Nachteil: Damit das Vorgehen funktioniert sind weitere Regeltermine nötig, also Querschnitts-Dailies (oder Bi-Weeklies) für alle Tester und Testautomatisierer. Die Vorteile wiegen diesen Nachteil allerdings bei weitem auf.


PS: In diesem Beispiel geht es lediglich um den Teilbereich der Qualitätssicherung, natürlich können aber auch viele andere Aspekte durch solche Boards teamübergreifend gesteuert werden.

Montag, 9. März 2015

Wir haben es mit Scrum versucht, aber es funktioniert nicht!

Bild: Unsplash / Mindspace Studio - Lizenz
Man hört ja in letzter Zeit immer wieder, dass Scrum so toll wäre. Ist es aber nicht. Wir haben es ausprobiert und es hat von Anfang an nicht geklappt!

Zum Beispiel diese Fixierung auf "shippable Code", also darauf, dass funktionierende Software wichtiger ist als detaillierte Dokumentation - wo kommen wir denn da hin? Zu jedem IT-Projekt gehören ein ausführliches Fachkonzept, eine Grob- und Feinspezifikation, eine Benutzerhilfe, ein Entwicklerhandbuch, ein Testkonzept und eine Testdokumentation. Das haben wir gleich als erstes eingeführt, schließlich ist das bei uns Best Practice seit 50 Jahren. Und wichtiger als die Software ist es auch, die schaut sich unsere Revision nämlich nicht an, die Unterlagen aber sehr genau.

Auch diese fixe Idee, dass die bisher fertiggestellte Software nach jedem Sprint sofort benutzbar sein soll haben wir verworfen. Wenn wir so früh mit dem Bugfixing anfangen bekommen wir die Features nicht umgesetzt, zu denen sich das Management für uns comitted hat. Ausserdem gibt es dafür die Bugfixing- und Integrationstestphase (als hätten diese Leute noch nie ein Wasserfallmodell gesehen). Übrigens: erzählen Sie uns jetzt nicht von "technischen Schulden". Für solche verkopften Theorie-Gedankenspiele haben wir keine Zeit.

Dann die Beschränkung der Teamgröße auf 5 - 10 Mitglieder, weil größere Teams angeblich ineffizient sind - wie soll das bitte funktionieren? Alleine für Konzeption, Dokumentation und Handbücher braucht man mindestens fünf Konzepter. Dann noch mindestens drei Software-Tester, schließlich muss die Anwendung ständig von Hand durchgetestet werden (diesen neumodischen Testautomatisierungs-Kram machen wir nicht). Dazu den PO, den Scrum Master und nicht zuletzt die Entwickler. Wir haben festgestellt, dass es mit weniger als 18 Mitgliedern nicht geht.

Als nächstes die Meetings. Das Daily Scrum soll in 15 Minuten machbar sein? Dann hat doch jedes Teammitglied nur weniger als eine Minute. Und kommen Sie mir nicht damit, dass die Teams eigentlich kleiner sein müssten, das hatten wir gerade schon. Auch die Idee, das Daily als "Stand Up" durchzuführen. Völlig unrealistisch. Wir haben uns bei einer durchschnittlichen Dauer von 50 Minuten eingependelt, natürlich muss man sich da setzen.

Zuletzt noch das Schlimmste: Der Scrum Master. Der hat permanent seine Kompetenzen überschritten. Statt einfach nur seinen Job zu machen indem er Termine einstellt und Meetings moderiert wollte er uns erzählen, wie die Methodik funktioniert und dass wir sie falsch umsetzen. Als ob wir uns da keine Gedanken gemacht hätten. Jede einzelne Verbesserung die wir an Scrum durchgeführt haben ist schließlich durch alle wichtigen Gremien gegangen und von denen für gut befunden worden, vom Betriebsrat bis zur Gleichstellungsbeauftragen.

Zum Glück konnten wir da zwei Fliegen mit einer Klappe schlagen. Wir haben seinen Vertrag nicht verlängert und lassen seine Aufgaben jetzt vom Product Owner wahrnehmen. So sind wir effizienter geworden und sparen sogar Geld.

Aber nichtmal das hat geholfen! Sie sehen, wir haben uns wirklich Mühe gegeben. Wir haben Scrum nicht nur eingeführt, wir haben es auch noch besser gemacht. Sogar einige der Grundlagen haben wir optimiert. Und trotzdem funktioniert es nicht. Scrum ist Mist!


[/Satire off]

Inspiriert von We tried baseball and it didn't work.

Donnerstag, 5. März 2015

Fachartikel: Testautomatisierung mit Xebium

Screenshot von sigs-datacom.de
Gerade den Hinweis bekommen: Nach zwei Jahren hat der Sigs-Datacom-Verlag endlich den Fachartikel zum Thema Testautomatisierung ins Netz gestellt, den ich seinerzeit zusammen mit Steffen Müller von Viskonz für die Zeitschrift Objekt Spektrum geschrieben hatte. Dazu eine kleine Anekdote: Dass der Artikel erst jetzt online publiziert wurde war keineswegs ein Versehen - wer schneller in den Suchmaschinen gefunden werden möchte muss einen kleinen Beitrag zahlen, und zwar eine "Bearbeitungsgebühr" von 100,- €. So sind sie, die Sitten in der Welt der Fachmedien. Aber ich will mich nicht beschweren, auch die Verlage müssen schließlich ihr Geld verdienen und leben nicht nur von Luft und Liebe.

Zum Artikel geht es hier (PDF).

Mittwoch, 4. März 2015

True Story: Personalvermittlungs-Fail

[Edit: Bitte auch die Kommentare lesen]

Ich hätte schon misstrauisch werden können als sich der Anrufer um 20.20 Uhr als Personalvermittler vorstellt. Wer ruft um diese Zeit beruflich an? Das Angebot klingt dann aber gar nicht schlecht: Eine Versicherung sucht für ein Projekt in Aachen "im Umfeld Lebensversicherung" einen Testmanager. Gewünscht sind ISTQB-Zertifizierung, Branchenerfahrung, Erfahrung mit Großprojekten und Expertise im Bereich Testautomatisierung, die "von Anfang an" durchgeführt werden soll. Alles in allem also ein durchaus anspruchsvolles Profil. Auf der anderen Seite nichts was ich nicht leisten könnte.

Aber.

Mehr als 60,-€ pro Stunde wären nicht drin. Das reizt natürlich zum (vergeblichen) Diskutieren: Dass es für diese Entlohnung niemanden mit dem entsprechenden Profil geben wird - glaubt er nicht. Dass man mit den Leuten die den Preis mitmachen keine "Testautomatisierung von Anfang an" schaffen wird - das sieht er anders. Naja, dann eben nicht. Ein paar Abschiedsfloskeln zum Schluss, und eigentlich will ich schon auflegen als er "aus reinem Interesse" noch eine letzte Frage stellen möchte: Was das denn überhaupt wäre, Testautomatisierung.

Jetzt mal im Ernst. Keine Ahnung was für Kunden dieser Herr vertritt - die IT-Töchter der Generali oder der Aachen Münchener? Was glauben die denn was für Personal die auf diesem Weg bekommen? Und wie suchen die sich ihre Dienstleister aus? Nur nach dem Preis? Dazu fällt mir nur eines ein:

Wenn Du denkst, die Arbeit mit Experten wäre teuer, dann warte ab wie teuer die Arbeit mit Amateuren wird.