The Center Trainers – Part 7: Hendrik

In diesem Jahr haben wir erfolgreich eine Tester-Masterclass im Center angeboten und viel gutes Feedback dazu bekommen. Ein Grund dafür ist das Engagement und Herzblut unserer Trainer im CIC. Im siebten Teil unserer Serie „The Center Trainers“ stellen wir euch Hendrik vor, der die Masterclass maßgeblich mit aufgebaut hat.

ibm-client-innovation-center-hendrik

Warum wolltest du Trainer im CIC werden?

Als langjähriger Software Tester wollte ich meine Erfahrungen mit den jüngeren Testern teilen. Mir geht es darum, ein gemeinsames Verständnis zum Testen hier im Center zu etablieren, sowie das Bewusstsein dafür zu schaffen, dass die Softwarequalität einen wichtigen Stellenwert innerhalb von Projekten und innerhalb des Centers einnimmt.

Seit wann bist du Trainer & welche Kurse gibst du?

Seit diesem Jahr gibt es die Test-Masterclass, was auch mein Einstieg in das Geben von Kursen bedeutete.

Wie hast du dich auf deine Rolle als Trainer vorbereitet?

Gemeinsam mit den Co-Tutoren habe ich überlegt, was wir von einer Masterclass und den Trainern insbesondere inhaltlich erwarten würden. Das wurde versucht entsprechend in den Kurs einzubauen.

Darüber hinaus haben wir von einem unserer erfahrenen Trainer hier im Center, Marcel, wertvolle Hinweise, wie so ein Kurs gestaltet werden kann, erhalten. Vielen Dank an dieser Stelle dafür!

Was sind deiner Meinung nach die wichtigsten Eigenschaften und Fähigkeiten, die man als Trainer mitbringen sollte?

Ein Trainer sollte fachliche Kompetenz ausstrahlen und sehr flexibel sein in Hinblick auf die Kursgestaltung, die Inhalte und die Zeit.

ibm-client-innovation-center-masterclass-trainer

Wovor hattest du die meisten Bedenken, bevor du deinen ersten Kurs gegeben hast?

Ich hatte keine Erfahrung mit Zeitmanagement. Würde die Zeitplanung im Kurs funktionieren? Was ist, wenn ein Modul viel schneller durch ist als angedacht? Was ist, wenn der Tag vorbei ist, aber eigentlich noch viele Inhalte offen sind? Am Ende hat alles gut geklappt, eigentlich besser als gedacht.

Was war die größte Herausforderung, die du bislang in einem deiner Kurse bewältigen musstest?

Nicht alle Trainer für die Test-Masterclass sitzen am Standort Magdeburg. So war man im Vorfeld der Schulung auf Telefonate und Mails angewiesen. Das war für die Vorbereitung des Kurses eine Herausforderung.

Was gefällt die besonders gut an deiner Rolle als CIC Trainer?

Ich habe so die Möglichkeit Wissen zu teilen und neue Kollegen fit für ihren Job zu machen. Dadurch wird ein echter Mehrwert für das CIC und für die Teilnehmer geschaffen.

Wie vereinst du deine Trainertätigkeit mit der täglichen Projektarbeit?

Es ist manchmal in der Tat nicht einfach den Spagat zwischen Abgabefristen im Projekt und zu erreichenden Meilensteinen bei der Kursvorbereitung und der Kursdurchführung zu schaffen. Das funktioniert bei mir durch gutes und konsequentes Zeitmanagement recht zuverlässig.

Wie stellst du dir deine zukünftige Entwicklung als Center Trainer vor und gibt es gibt es andere Kursformate, die dich interessieren oder die du bereits geplant hast?

Ich plane, die Test-Masterclass regelmäßig fortzuführen. Das will ich als Basis für Tester auf jeden Fall beibehalten. Ich könnte mir weiterhin vorstellen für erfahrene Tester Thementage mit Bezug zu aktuellen Trends in der Qualitätssicherung durchzuführen.

Welche Tipps würdest du jemanden geben, der selber als Trainer im CIC Kurse geben möchte?

Sprecht mit Leuten, die Erfahrungen im Halten von Schulungen haben. Nehmt deren Tipps und Ratschläge an. Besucht eine entsprechende Schulung. Das hilft ungemein, damit euer Kurs bei den Teilnehmern gut ankommt.

Advertisements

Blockchain at CIC

Regelmäßig nutzen wir das breitgefächerte, technische Know-How des Centers, um Kollegen, die Interesse an einem Thema haben, hausintern zu schulen. Robert wollte gern mehr über Blockchain wissen und fand sich daher im Einführungskurs des Centers wieder.

Robert

Alle reden derzeit über „die Blockchain“ und vor allem IBM hat sich in diesem Kontext als Vorreiter etabliert und arbeitet intensiv mit Kunden weltweit zusammen, um ihnen zu zeigen, was Blockchain für sie tun und wie IBM ihnen auf ihrem Weg zur Einführung dieser Technologie helfen kann. Natürlich haben wir auch im CIC Experten, die sich auf diesem Gebiet auskennen. Gleichzeitig haben wir auch viele Kollegen, die von der neuen Technologie bereits gehört haben, aber keiner so recht weiß, was wirklich dahinter steht. Es ergaben sich Fragen wie: Was ist eine Blockchain? Was kann man mit dieser neuen Technologie anfangen und wie nutzt IBM die Blockchain? Um diese Fragen zu beantworten, haben sich drei unserer Blockchain-Experten bereit erklärt einen Einführungskurs im Center anzubieten.

blockchain

Los ging es damit was die Blockchain überhaupt ist. Eingeführt 2008 in einem Whitepaper von Satoshi Nakamoto und am 03. Januar 2009 released, war Bitcoin die erste medienwirksame Ausprägung der Blockchain. Sie ist ein sogenannter „shared ledger“. Um es bildlich zu beschreiben, die Blockchain ist eine Art Buch, in der alle Transaktionen stehen, die im Kontext der Blockchain gemacht wurden. Diese Historie kann nicht einfach verändert werden und jeder Teilnehmer der Blockchain hält eine Kopie bei sich. Wird ein Eintrag hinzugefügt, kontrollieren die Teilnehmer in der Blockchain, ob diese Transaktion korrekt ist. Verändert werden können Einträge hierbei nur, indem ein neuer Eintrag angelegt wird.

Mit dieser Einführung wussten wir zumindest wie eine Blockchain definiert ist, gleichzeitig war noch nicht klar, wie sichergestellt werden kann, dass Einträge korrekt sind. Genau dieser Punkt wurde in Form eines Spiels deutlich. Das “Problem der Byzantinischen Generäle” half hierbei: Mehrere Generäle wollen eine Stadt angreifen, dabei sind die Generäle an unterschiedlichen Stellen aufgestellt und können nur über einen Boten miteinander kommunizieren. Unter den Generälen gibt es Verräter. Der Angriff ist nur dann erfolgreich, wenn alle Generäle gleichzeitig angreifen. Die Spieler stellten sich also auf und mussten sich nun untereinander austauschen, ob ein Angriff oder ein Rückzug stattfindet. Hierfür zählten sie einfach wie oft sie die Nachricht „Angriff“ und wie oft sie die Nachricht „Rückzug“ gehört haben. So konnten sie sicher gehen, dass sie die richtige Wahl treffen. Das System würde nur fehlschlagen, wenn es mehr Verräter als gute Generäle gibt.

Mit der Geschichte der Byzantinischen Generäle war somit schon mal ein Verständnis für die Problematik an sich geschaffen, aber wie kann die Byzantinische Fehlertoleranz wirklich in der Praxis erklärt werden? Mit Sprinkler-Systemen im öffentlichen Raum zum Beispiel. Wenn ein Sprinkler fehlerhaft ist, möchte man nicht den ganzen Raum unter Wasser setzen. Die Byzantinische Fehlertoleranz gibt genau diesen Spielraum, dass auch fehlerhafte Daten in ein System einfließen können, aber sobald die Mehrheit der Teilnehmer die richtigen Daten haben, gibt es keine Möglichkeit, dass Fehler das System beeinflussen. Genau wie beim Sprinklersystem kontrollieren also die Teilnehmer der Blockchain, ob ein Eintrag korrekt ist oder nicht. Somit ist gewährleistet, dass die Blockchain-Historie nicht geändert werden kann.

Wie so oft mit neuen Technologie ist die öffentliche Präsenz erstmal groß. Zunächst scheint es als könnte man alle Probleme, die man vorher hatte, endlich lösen. Doch genau wie bei allen anderen Trends kommt auch die Blockchain an ihre Grenzen. Dementsprechend war ein weiterer Aspekt des Kurses, zu klären wann der Einsatz der Blockchain-Technologie sinnvoll sein kann.

Die Fragen, die man sich hierbei stellen sollte:

  • Ist die Blockchain wirklich nötig?
  • Gibt es schon andere Technologie, die das Problem auch lösen könnten – vielleicht sogar besser?

Dazu wurden von den Kursleitern Beispiele genannt und die Kursteilnehmer sollten diskutieren, ob der Einsatz der Blockchain sinnvoll ist.

Eine Kaffeeliste für die Firma auf Blockchain-Basis? Könnte machbar sein. Da die Transaktionen unveränderlich sind, könnte niemand mehr beim Kaffee schummeln. Gleichzeitig stellt sich aber die Frage, ob es den Aufwand für eine Firma Wert ist? Wahrscheinlich eher nicht – Stift und Zettel gehen als Alternative auch. Wann könnte dieses Beispiel interessant werden? Vielleicht, wenn mehrere Firmen an der Kaffeeliste teilnehmen.

Wo kommt mein Essen wirklich her? Könnte zum Beispiel ein guter Anwendungsfall für Firmen sein, um den Kunden zu zeigen wo ihre Produkte herkommen. Die Historie der Lieferkette wäre für alle einsehbar und unveränderbar.

Für die Teilnehmer wurde schnell klar, dass, bevor man die Blockchain wirklich zum Einsatz bringt, alle Möglichkeiten und Probleme in Betracht gezogen werden sollten.

Natürlich wurden auch die technischen Aspekte beleuchtet. Die Kursteilnehmer konnten erfahren wie eine Blockchain im Allgemeinen aufgebaut ist und im Speziellen wie Hyperledger, als Blockchain Variante von IBM unter der Linux Foundation, funktioniert. Abschließend gab es einen kleinen Ausblick auf die Zukunft der Blockchain und weitere Entwicklungen in diesem Bereich. Alles in allem war der Workshop ein tolles Ereignis mit vielen Insights zu einem Thema über das viel gesprochen, aber zu dem es wenig Erklärungen gibt.

Grow@CIC-Talentprogramm

Grow@CIC ist ein europaweites Talentprogramm für die IBM Client Innovation Center mit dem Ziel einer bestmöglichen Vorbereitung der Teilnehmer auf zukünftige Leadership-Rollen. In dieser Zeit erhalten Kollegen mit Leadership-Potential face-to-face Trainings, E-learnings, Mentoring, Shadowing sowie diverse Möglichkeiten zum Austausch von Erfahrungen und zum Netzwerke knüpfen mit dem Senior Leadership Team der IBM. Ende letzten Jahres sind wir europaweit mit dem ersten Talent Team in das Programm gestartet. Hier ein erster Erfahrungsbericht von Maik.

ibm-client-innovation-center-maik

Hallo, ich bin Maik und seit drei Jahren im Center in Magdeburg als Frontend Developer angestellt. Ende letzten Jahres bekam ich zusammen mit vier Kollegen die einmalige Chance an einem neuen Programm innerhalb der CIC’s Europe teilzunehmen – Grow@CIC.

Grow@CIC startete mit der Einführung in das Programm – welche Inhalte erwarten uns, in welchem zeitlichen Rahmen und was ist das Ziel des einjährigen Trainings. Nach dem Kick Off mit unserer europäischen Human Resources-Leitung wurde uns allmählich klar, egal was noch auf uns zukommen würde, es wird eine super Gelegenheit sich mit Kollegen der anderen CIC Lokationen außerhalb Deutschlands auszutauschen. Denn an dem Programm nahmen viele Kollegen aus den Westeuropäischen Centern teil: England, Niederlande, Italien, Frankreich und Schweden.

Voller Vorfreude zu erfahren was uns erwarten würde, ging es Anfang Dezember gleich zu einem zweitägigen Schulungs-Event nach Wien. Vienna calling 😉
Dort nahmen wir an einem sehr interessanten und amüsanten Storytelling-Workshop teil. Die Trainer zeigten uns Mittel und Nutzen eines guten Storytellings und ließen uns in Gruppen Beispiel-Stories entwickeln und „vorspielen“. Der interaktive Teil fiel mir persönlich anfangs schwer, da ich mich etwas scheue Englisch zu sprechen. Gerade das Interaktive half aber schnell das Eis zwischen den Moderatoren und Teilnehmern zu brechen. Neben dem Storytelling-Training bietet uns das Programm Möglichkeiten Mentoring oder Shadowing umzusetzen und Schulungen auf verschiedenen Plattformen in Anspruch zu nehmen, z.B. zum Thema Leadership und Softskills. Insgesamt geht es also um die persönliche Entwicklung und Festigung von Skills.

Das spielerische Kennenlernen animierte beim Abendessen dann – landestypisch natürlich Wiener Schnitzel 😉 –  zu lebhaften Gesprächen zwischen den Teilnehmern. Es gab regen Austausch zu allen möglichen Themen, auch fernab der IT, wie zum Beispiel Essgewohnheiten, Fußball oder „false friends“ Vokabeln der unterschiedlichen Sprachen.

ibm-client-innovation-center-grow-at-cic

Am nächsten Tag ging es mit dem Workshop zum Thema HBDI (Herrmann Brain Dominance Instrument) weiter, bei dem wir anhand unserer natürlichen Präferenzen und Denkweisen in vier unterschiedliche Gruppen aufgeteilt wurden. Diese Einteilung und auch das Erkennen seiner eigenen Denkweise in Bezug auf Emotionalität, Kreativität und analytischem Denken, half uns später beim Hineinversetzen in unsere Kunden oder Kollegen.

Am Ende des zweiten Tages wurden wir dann mit unseren „Challenges“ konfrontiert. Denn das Programm enthält, neben den Trainings und dem Austausch mit den Kollegen aus den anderen Centern, reale Herausforderungen, die die CIC`s Europe derzeit beschäftigen. Für diese Challenges haben sich Teams gebildet, deren Aufgabe es sein sollte im verbleibenden halben Jahr, innerhalb des Programms Lösungsansätze zu erarbeiten. Im Herbst endet dann Grow@CIC mit einem erneuten, persönlichen Treffen der Kollegen und einer weiteren interessanten Schulung.

Wir haben viel mitgenommen aus den verschiedenen Schulungen und Ansätzen Probleme zu lösen. Außerdem war die Zusammenarbeit mit den europäischen Centerkollegen eine interessante Erfahrung. Wir sind an der Herausforderung gewachsen und blicken auf eine spaßige, aber auch fordernde Zeit zurück, die uns andere Länder und unterschiedliche Denkweisen näher brachte. Aber vielleicht werden unsere Lösungsvorschläge bald in die Tat umgesetzt. Es wäre klasse, wenn wir sagen können, dass wir aktiv an neuen Programmen der Center mitgearbeitet haben – wir sind gespannt. 🙂

Das Professional Scrum Developer Training

Vor einiger Zeit fand in unserem Magdeburger Center der Kurs Professional Scrum Developer statt. Der Kurs bestand aus einer dreitägigen Schulung und der Chance auf eine Zertifizierung als – wer hätte das erwartet – Professional Scrum Developer. Unser Kollege Paul war dabei.

Paul-author.png

Der Kurs war so aufgebaut, dass ein Vor- beziehungsweise Nachmittag aus je einem Theorieblock und einem Sprint bestand. Der Mittwochvormittag und der Freitagnachmittag bildeten dabei Ausnahmen.

  Tag 1 | Mittwoch Tag 2 | Donnerstag Tag 3 | Freitag
Vormittag Scrum Basics, ALM
Einrichten der IDE
Agile Testing
Sprint II
Quality Code
Sprint IV
Nachmittag Sprint I Emergent Architecture
Sprint III
Scrum Challenges
Abschluss und Fragen

Gehalten wurde der Kurs von Andreas, der tagtäglich als Product Owner in Scrum-Projekten unterwegs ist. Die Teilnehmer wurden in drei Teams aufgeteilt, die dann für den Zeitraum der drei Tage zusammen gearbeitet haben. Jedes Team musste sich nur einen eigenen Namen ausdenken und schon stürzten wir uns als Team Hollywood, Plan B und Team RockIT in die folgenden drei Tage.

Tag 1

An unserem ersten Tag verbrachten wir den Vormittag mit dem Schwerpunkt Scrum Basics und Application Lifecycle Management (ALM). Der Scrum-Block galt vor allem den Leuten, die bisher noch nichts mit Scrum im Projektumfeld zu tun hatten. Nachdem wir nun wussten, was Scrum ist, aus welchen Rollen ein Scrum-Team besteht, welche Artefakte und Events es gibt, war das nächste Ziel einen Einblick in das Thema ALM zu bekommen. Vor allem eine etwaige Verbindung zu Scrum hat uns natürlich im Kontext des Kurses interessiert. Wir kamen zu dem Schluss, dass sich Scrum sehr gut in ALM integrieren lässt, da gerade die Tools im Rahmen des Application Lifecycle Managements die Stärken von Scrum (dynamisch, flexibel) betonen.

Im Anschluss an unseren ersten Theorieblock galt der Rest des Vormittags dem Einrichten der Entwicklungsumgebung. Und wie jeder weiß, oft ist es egal, wie gut man so etwas vorbereitet, irgendetwas geht immer schief und funktioniert nicht auf Anhieb. So natürlich auch bei uns. Demnach mussten wir noch einen großen Teil des Nachmittags mit der Einrichtung verbringen. Irgendwann hatten wir dann aber bei den meisten Teilnehmern einen lauffähigen Stand, um so mit dem ersten praktischen Block des Kurses zu starten, unserem ersten Sprint. Der Fokus in diesem Sprint lag vorerst auf dem Kennenlernen der Anwendung. Hier konnten wir uns mit der Anwendung vertraut machen und bereits die ein oder andere Story umsetzen. Nach der Sprintplanung von rund 15 Minuten hatte jedes Team etwa 90 Minuten Zeit, um das umzusetzen, was sie sich im Rahmen der Planung vorgenommen haben. Wenn Rückfragen zu Stories aufkamen, stand Andreas in seiner geübten Rolle des Product Owner parat. Abgeschlossen wurde unser erster Sprint mit dem Review. Hier ging es darum, dem Product Owner und den Stakeholdern die umgesetzten Arbeitsergebnisse vorzustellen. Für die Retrospektive war an diesem Nachmittag keine Zeit mehr und wir konnten nach der Review den ersten Tag beenden.

Tag 2

ibm-client-innovation-center-scrum-starfish

Der zweite Tag begann mit dem letzten Teil unseres ersten Sprints, der Retrospektive. Anhand des Modells, dass an einen Seestern angelehnt ist (siehe Abbildung rechts), hat sich jedes Team zu den Punkten „Stop Doing“, „Start Doing“, „Keep Doing“, „More Of“ und „Less Of“ zusammengesetzt und Maßnahmen beschlossen, um die herausgearbeiteten, negativen Punkte im nächsten Sprint besser zu machen.
Unser erster Theorieblock für den Tag umfasste den Bereich des Agilen Testings. Neben allgemeinen Themen, wie Arten von Tests oder Strategien für die Umsetzung von Tests, sind wir darauf eingegangen, wie intensiv der ein oder andere diese Dinge im Projekt bereits einsetzt und was man dort verändern beziehungsweise verbessern könnte. Weitere Themen waren Test-Driven-Development, Warum testen wir denn überhaupt? und Tools, die einem schlichtweg dabei helfen, die Ergebnisse dieser teils automatisierbaren Tests auszuwerten und sinnvoll darzustellen. Im Anschluss an den Block folgte unser zweiter Sprint, diesmal mit dem Fokus auf das Schreiben von Unittests im Zuge der Umsetzung der Stories. Nachdem wir diesen dann in einem ähnlichen Zeitrahmen wie Sprint Nummer 1 mit all seinen Events durchgeführt hatten, schallte der Gong zur Mittagspause durch den Flur.

Nach der wohlverdienten Pause ging es nun an den zweiten Block für diesen Tag. Bei dem Thema Emergent Architecture ging es vor allem darum, wie man den riesigen Themenbereich der Architektur in das Konstrukt Scrum integriert, welches auf kurze Entwicklungszyklen und dynamische Anforderungen ausgelegt ist. Bei jedem Sprint sollte das Ziel sein, das an Architektur zu modellieren und zu bauen, was im Rahmen dieses, und auch nur dieses, Sprints notwendig ist. Das ganze System ist nicht vor dem eigentlichen Start der Entwicklung komplett zu modellieren, sondern wird stetig um die notwendigen Anpassungen erweitert.

Abgeschlossen wurde der Tag mit unserem dritten Sprint. Einen Fokus im Rahmen dieses Sprints auf das vorangegangene Theoriethema zu legen, war hier nicht ganz so einfach, da die Stories aufgrund der Mini-Sprints recht klein waren. Nichtsdestotrotz haben wir alles versucht umzusetzen, was im Bereich Architektur und diesen Stories möglich war.

Tag 3

Unser letzter Tag fing erneut mit einem Theorieblock an. Das Thema diesmal war Quality Code. Neben verschiedenen Prinzipien für sauberen Code – wie Don‘t Repeat Yourself (DRY), Single Responsibility Principle (SRP), Test Driven Design (TDD) und vielen anderen – sind wir im Rahmen des Kurses darauf eingegangen, wie man die Qualität in seinem Code auf einem hohen Niveau hält. Zudem haben wir gelernt, dass vor allem Tools im Bereich der Continuous Integration hier den Entwicklern einiges an Arbeit abnehmen können und zeitgleich die Effizienz und Qualität steigern. Automatische Build- und Test-Prozesse können beispielsweise frühzeitig zeigen, dass bestimmte Dinge nicht funktionieren oder vielmehr nicht so funktionieren, wie es beabsichtigt ist.

PSD_Schulung_02.jpgNach einer kurzen Pause starteten wir turbulent und mit Spannung(en) in unseren vierten und letzten Sprint im Rahmen dieses Kurses. Die Prinzipien, die wir im Rahmen des Theorieblocks kennengelernt hatten und nicht ohnehin schon aus Gewohnheit verwenden, konnten wir gleich anwenden und ausprobieren.

Nachdem wir auch diesen finalen Sprint wieder mit Review und Retrospektive abgeschlossen hatten, folgte ein letzter Theorieblock über Scrum Challenges. Dieses Thema umfasste vor allem das Identifizieren und Bewältigen von üblichen Herausforderungen und Fehlfunktionen, denen ein Scrum-Entwickler-Team ausgesetzt sein kann. Dabei sind wir auf Fragen – wie „Was passiert mit Aufgaben, die nicht fertig wurden?“, „Wie geht man mit schwierigen / nicht schnell lösbaren Themen wie fehlendem Skill um?“ oder „Wie kann ich das vorhandene Wissen auf soviele Köpfe wie möglich verteilen?“ – eingegangen. Zu guter Letzt haben wir verschiedene Beispielfälle diskutiert und gemeinsam besprochen, was man in diesen Szenarien als Team tun kann.

Zertifizierung

Die Prüfung ist ein Multiple-Choice-Online-Test. Er besteht aus 80 Fragen, teilweise Scrum-Basics, teilweise Fragen aus Themen-Komplexen, die nur im Rahmen der Developer-Rolle wichtig sind. Für die Beantwortung der Fragen hat man 60 Minuten Zeit. Zum Bestehen muss man 85% der Fragen (68) korrekt beantworten.

Für die Vorbereitung hatten wir zum einen den Foliensatz, den wir im Rahmen der Schulung durchgegangen sind, sowie den Scrum Guide und Open Assessments. Diese Test-Prüfungen kann man auf Scrum.org so oft durchführen, wie man möchte. Dort gibt es für die verschiedenen Rollen jeweilige Probetests. In diesen Tests bekommt man 30 Fragen, die man innerhalb von 30 Minuten beantworten muss. Am Ende bekommt man dann eine Auflistung der Fragen und die Information, was man korrekt angekreuzt hat und was nicht. Wenn man die beiden Dokumente nochmal in Ruhe durchgeht und das ein oder andere Open Assessment macht, ist man für die Prüfung dann auch sehr gut vorbereitet.

Vielen Dank fürs Lesen und …

Scrum on! 🙂

PSD_Schulung_01.jpg

 

Gemeinsam lernen ist immer besser als allein – Design Thinking Badge mit den Kollegen

Weiterbildung wird bei uns im IBM Client Innovation Center groß geschrieben und neben der Projektarbeit möglich gemacht. Geht man durch die Flure sieht man täglich mindestens einen Kollegen, der in eine spannende Schulung vertieft ist oder jemanden, der gerade ein Training vor Ort erhält. Mahmoud hat den Vorteil erkannt, dass viele Kollegen Design Thinking kennenlernen wollen und hat das Training dazu in der Gruppe absolviert.

IBMClientInnovationCenter-Mahmoud

Am besten lernt man etwas Neues als Kind.

Für mich ist es dafür jetzt zu spät. 😊 Das Zweitbeste ist, in einer Gruppe mit motivierten Kollegen zu lernen, sich darüber auszutauschen und gemeinsam dazuzulernen und seinen Horizont zu erweitern.

Es war meinen Kollegen in München und mir eine große Freude, Design Thinking in einer Gruppe und vor allem mit Kuchen und Kaffee zu lernen. 😊 Kuchen macht alles einfach immer ein bisschen besser, auch wenn es Design Thinking ist, was an sich ja schon ziemlich cool ist.

Die Schulung war sehr interessant und durch Videos und Rollenspiele sehr praxisorientiert. Nach der Schulung hatten wir einen besseren Überblick, wie die Methode Design Thinking funktioniert. Ich verstehe nun endlich, was Hills sind oder wie man seine Empathie trainiert.

Natürlich wird einem auch beigebracht welche Vorteile Design Thinking mit sich bringt und warum man es überhaupt einsetzt. Danke an meine Kollegin Silja, für die Idee das Training gemeinsam in der Gruppe zu machen.

IBMClientInnovationCenter-Design-Thinking-Badge_k

Und das Beste an der Geschichte ist, wir haben alle unseren Badge bekommen, nachdem wir uns intensiv mit dem Gelernten auseinander gesetzt haben und durch das Self-Assessment gekommen sind. Yay.

Ich kann es kaum erwarten Design Thinking in einem Projekt einzusetzen und es somit wirklich zu erleben.

Cheers, Mahmoud

The Center Trainers – Part 6: Martin

In diesem Jahr haben wir das erste Mal eine Tester-Masterclass im Center angeboten und viel gutes Feedback dazu bekommen. Ein Grund dafür ist das Engagement und Herzblut unserer Trainer im CIC. Im sechsten Teil unserer Serie „The Center Trainers“ stellen wir euch Martin vor, der den Automatisierungspart der Tester-Masterclass aufgebaut hat.IBMClientInnovationCenter-Martin

Warum wolltest du Trainer im CIC werden?

Die Java-Masterclass, als 4-wöchiges Intensivtraining für Absolventen, ist mittlerweile im Center schon gut etabliert. Daduch entstand bei zwei Kollegen aus unserer Test-Community die Frage, warum es eigentlich keine Masterclass für Tester gibt.

Ich kenne die beiden noch von unserem vorherigen Arbeitgeber, wo ich Ansprechpartner für die Testautomatisierung war. Als die beiden mir dann von ihrer Idee eine Test-Masterclass ins Leben zu rufen erzählten und fragten, ob ich nicht etwas über die Automatisierung von Tests sagen könnte, wollte ich natürlich helfen.

Seit wann bist du Trainer & welche Kurse gibst du?

Ich arbeite ja erst seit Anfang 2017 hier im Center und habe jetzt im Zuge der Test-Masterclass Anfang 2018 das erste Mal mithelfen können.

Ich habe dabei einen Kurs über die Testung im agilen Umfeld geleitet und etwas zur Theorie der Testautomatisierung gesagt. Das heißt – in welchen Teststufen können welche Tests wie automatisiert werden? Welche Voraussetzungen gibt es? Was muss beachtet werden, wenn man Testautomatisierung einführen möchte? Und so weiter.

Die beiden Kurse sind thematisch natürlich eng beieinander, da besonders bei agilen Ansätzen der Softwareentwicklung die automatisierte Testung elementar ist.

IBMClientInnovationCenter-ISTQB-masterclass

Wie hast du dich auf deine Rolle als Trainer vorbereitet?

Glücklicherweise hatte ich privat noch ein paar Folien, die ich inhaltlich gut nutzen konnte, um die Kurse aufzubauen und hatte früher schon Kurse zu diesen Themen gegeben.

Dazu kam noch ein bisschen Recherche im Netz und die Frage, wie man die Inhalte am besten vermittelt. Dabei dachte ich, dass reiner Frontalunterricht wahrscheinlich weniger spannend für die Teilnehmer ist. Also habe ich überlegt, was man in Gruppenarbeit oder auch interaktiv machen kann. Einer unserer erfahrenen Trainer hier im Center, Marcel, hat uns auch noch ein paar nützliche Tipps gegeben.

Was sind deiner Meinung nach die wichtigsten Eigenschaften und Fähigkeiten, die man als Trainer mitbringen sollte?

Neben dem Fachwissen ist sicherlich eine Gewisse Lockerheit und Selbstvertrauen notwendig, sodass man auf spontane Umstände und Fragen eingehen kann.

Ansonsten hilft es, wenn man freundlich und natürlich auftritt. Trotzdem ist ein Trainer keiner, der alles weiß, sondern speziell im Rahmen der Masterclass ein Kollege, der sein Wissen auf einem speziellen Gebiet mit seinen anderen Kollegen teilen möchte.

The Center Trainers

Wovor hattest du die meisten Bedenken, bevor du deinen ersten Kurs gegeben hast?

Zum einen, ob ich mit der Zeitplanung halbwegs gut liege. Wenn man ein-einhalb Tage plant, kann schnell etwas dazwischen kommen. Ich hatte Sorgen, ob ich viel zu schnell oder zu langsam sein würde.

Zum anderen, ob ich das Thema übermitteln kann ohne dass sich die Teilnehmer langweilen. Zum Beispiel, dass sie bei der Einführung nicht richtig abgeholt werden, große Teile schon kennen oder der Kurs zu langweilig aufgebaut ist. Jeder hat bestimmt schon mal einen Vortrag gehört, bei dem man am Ende zu Tode gelangweilt rausgeht und nichts mitgenommen hat.

Was war die größte Herausforderung, die du bislang in einem deiner Kurse bewältigen musstest?

Ich hab den Übergang von einem zum nächsten Thema nicht hinbekommen, bin dann ins Stocken geraten und war für eine gefühlte Ewigkeit vollkommen raus. An dieser Stelle wusste ich nicht, was ich weiter sagen wollte. Kurz stand ich hilflos da, dann hab ich eine der nächsten Folien gesucht und ohne große Überleitung gemeint: „So wir machen jetzt hier weiter“  – zum Glück hat keiner der Teilnehmer komisch reagiert.

Was war die witzigste Anekdote?

Ich wollte Blätter mit Begriffen an die Leinwand pinnen und immer wenn ich eins anpinnen wollte, sind zwei andere heruntergefallen, wenn ich die wieder anpinnen wollte, ist wieder mindestens ein anderes abgegangen. Nachdem ich fertig war und den nächsten Begriff gesucht hatte, ging es wieder los – dann hab ich nach Klebestreifen gesucht.

Was gefällt die besonders gut an deiner Rolle als CIC Trainer?

Besonders gut gefällt mir, dass man selbst die Chance hat über den Tellerrand des täglichen Projektgeschäfts zu schauen. Außerdem erhält man durch Fragen der Teilnehmer einen anderen Blick auf Dinge, die einem selbst klar schienen, dann aber vielleicht gar nicht mehr so klar sind.

Wie vereinst du deine Trainertätigkeit mit der täglichen Projektarbeit?

Ich hatte Glück, dass bei uns im Projekt um den Jahreswechsel gerade keine heiße Phase war. Ich kann mir vorstellen, dass es da schon mal problematischer werden kann. Allerdings kommt so ein Vortrag meist nicht spontan und innerhalb von ein bis zwei Monaten kann man sicher ein paar Stunden für Vorbereitungen einplanen. Solange man den Kollegen vom Projekt Bescheid gibt, dass man an diesem/diesen Tag(en) entsprechend eingebunden ist, stellt das meist keine Hürde dar.

Wie stellst du dir deine zukünftige Entwicklung als Center Trainer vor und gibt es andere Kursformate, die dich interessieren oder, die du bereits geplant hast?

Trainer zu sein hat mir viel Spaß und mich auch ein wenig Stolz gemacht. Von daher würde ich auch in Zukunft meine Hilfe gern anbieten. Da ich in meinem jetzigen Projekt jedoch kaum mit Testautomatisierung in Berührung komme, würde ich mich über Kollegen freuen, die aktuellere Praxiserfahrungen haben und mit mir den Kurs zusammen halten können. Dann würde ich auch versuchen noch mehr praktische Beispiele zur Theorie zu zeigen.

Ansonsten bin ich im aktuellen Projekt mehr mit der eigentlichen Entwicklung beschäftigt und könnte mir gut vorstellen, etwas über Entwurfsmuster, CleanCode in Verbindung mit C# und/oder Java beizusteuern. Ich denke alle Entwickler haben schon Code gesehen, wo sie dem Autor eine entsprechende Schulung gewünscht hätten.

Welche Tipps würdest du jemandem geben, der als Trainer Kurse im CIC geben möchte?

Wenn jemand gern selbst Trainer sein möchte, bringt er schon die wichtigste Voraussetzung mit: Motivation. Jetzt muss er „nur noch“ mit seiner eigenen Motivation die Teilnehmer motivieren. Dazu zählt, denke ich, wie oben schon gesagt, Lockerheit und Zusammenarbeit mit den Teilnehmern.

Weiterhin sollte man mit den Vorbereitungen rechtzeitig anfangen, sonst ist am Ende zu wenig Zeit für diese und man kann die Inhalte nicht so vermitteln, wie man es sich selbst gewünscht hätte.

Von Architekten, die keine Häuser bauen

Zurzeit ist Rico noch Allrounder in seinem Projekt. Ob Projektleitung, Entwicklung, Testing oder Administration, er hat überall seine Finger im Spiel. Die heute beschriebene Schulung ist für alle angehenden Architekten Pflicht und bringt Rico seinem Ziel „Lead Architect“ zu werden wieder einen Schritt näher.

Rico

Kürzlich fand zwei Tage lang der Kurs „Component Modeling“ in Magdeburg statt. Dieser gehört zu einer Reihe von Schulungen, die jeder angehende Software Architekt absolviert und gehört damit zum Handwerkszeug auf diesem Karrierepfad.

Das Interesse der Kollegen an der Schulung war groß, der Schulungsraum war bis auf den letzten Platz ausgebucht. Unsere drei Lehrer zeigten uns in theoretischen und praktischen Abschnitten, wie man von einem Anforderungsdokument zu einem konkreten Komponenten-Modell kommt, aus dem dann wiederum das eigentliche Programm, die Software, entsteht.

Rico

Eigentlich braucht man nur drei einfache Schritte – identifizieren, spezifizieren und implementieren – fertig. Die dafür geplanten zwei Tage zeigten aber schon, dass es damit nicht getan ist. Die Tücke steckt wie so oft im Detail und jeder dieser Schritte wird je nach Umfang der anstehenden Anforderungen iterativ mehrfach wiederholt. Dabei wird in jedem der Schritte das so entstehende Komponenten-Modell verfeinert und immer weiter ausgearbeitet.

Ziel ist es, alle im Anforderungsdokument erfassten funktionalen und nicht-funktionalen Anforderungen, Geschäftsregeln und Kundenvorgaben abzubilden. Zur Darstellung bedient man sich der Unified Modeling Language (UML). Sie bietet Formalien, um die Bestandteile eines Systems grafisch darzustellen und so für den Menschen optisch erfassbar zu machen.

Diese Umwandlung vom Dokument zur Grafik wird selten im ersten Wurf gelingen. Zusätzlich ist in der Praxis selten ein Anforderungsdokument vollständig und unveränderlich. Es ergeben sich immer wieder neue Aspekte im Verlauf eines Projektes, die eingearbeitet werden müssen.

Hinzu kommt, dass es natürlich nicht nur einen Typ von Komponenten-Modell gibt. Neben dem Component Relationship Diagram (CRD) hat man beispielsweise auch noch Component Interaction Diagrams (CID) zur Verfügung, mit denen sich die dynamischen Abläufe zwischen Komponenten untereinander abbilden lassen.

All diese Werkzeuge und Techniken wurden uns in diesen zwei Tagen theoretisch erläutert. Im Anschluss an jeden Theorieblock konnten wir das Erlernte an einem realen Fallbeispiel üben. Dabei agierten die Lehrer im Hintergrund und beobachteten uns bei der Arbeit. Am Ende jeder Übung wurden, wie im realen Projektleben, die Ergebnisse vorgestellt und im Kurs diskutiert.

Wie häufig bei iterativen Abläufen kam bei uns die Frage auf, wie häufig man denn diesen oder jenen Schritt wiederholen muss und nicht selten war die Anwort: „it depends – kommt drauf an“. Hier waren die Erfahrungsberichte der Trainer aus ihrem Projektleben sehr interessant. Sie zeigten uns, wie man im Projektalltag die passenden „Abbruchbedingungen“ für die Iterationen finden oder wie die teils komplexen und sperrigen Abläufe aus der Theorie in die Praxis übertragen werden können.

Insgesamt waren alle Teilnehmer des Kurses am Ende sehr zufrieden und um ein neues Werkzeug reicher, das uns zukünftig bei der Arbeit im Projekt hilft. Ich persönlich freue mich schon auf die nächste Schulung auf dem Weg zum Architekten.