Scrum in der Praxis: Part I, der erste Sprint

In unserer Rubrik Tech Talk stellen wir euch heute und in weiteren Beiträgen eine der bekanntesten agilen Methoden vor – Scrum. Damit wollen wir euch einen Einblick in den Projektalltag vieler unserer Kollegen geben und die unterschiedlichen Phasen dieser Entwicklung erklären. Ihr habt noch nie in der agilen Entwicklung gearbeitet? Dann folgt aufmerksam unserer Reihe „Scrum in der Praxis“.

Viele von uns waren bereits Teil von Scrum-Teams und in der agilen Entwicklung beschäftigt. Wir haben in Retrospektiven, Refinements, Plannings und im Sprint-Verlauf allgemein Sicherheit gewonnen. Trotzdem gibt es Ausnahmesituationen, die selbst im strukturierten, agilen Vorgehen Unsicherheit auslösen und wie Corner Cases eines ansonsten klaren Ablaufs wirken. Am Anfang war der Anfang und die Frage: Wie fängt man eigentlich an? Wenn nichts da ist, Boards und Diagramme noch leer? Wir kennen das Schätzen und Schneiden innerhalb unseres Backlogs, das Verfeinern. Und dank unserer Velocity haben wir eine Maßgabe wieviel wir in den nächsten Sprint einplanen. Aber wie geht man vor, wenn es keinen vorhergehenden Sprint und keine Velocity gibt? Wir reden von einem Fabelwesen, dem man nicht oft beiwohnen darf: dem ersten Sprint.

Antipattern und agiler Mythos: Sprint 0

Aber ja, es gibt sie, die ersten Sprints. Nur der Mythos vom Sprint 0 sollte besser ein Mythos bleiben. Nach Lehrbuch ist kein Sprint 0 vorgesehen, trotzdem poppt er immer mal wieder auf. Inzwischen wird der Sprint 0 sogar oftmals als Anti-Pattern bezeichnet. Unter der Annahme, dass man in einem Sprint 0 vorbereitende Aufgaben erledigt, schleichen sich meistens die ersten Verfälschungen einer Schätzung ein. Was sind solche vorbereitenden Aufgaben? Erste Meetings aufsetzen und daran teilnehmen, eine Entwicklungsumgebung einrichten? Meetings und Setups oder sonstige technische Checks sind Aufgaben, die in jedem Sprint auftreten (können) und womit man immer rechnen darf. Jeder Sprint soll Mehrwert für den Kunden erzeugen. Tut es das nicht, dann ist es kein Sprint. Daher ist es laut Lehrbuch nicht richtig von Sprint 0 zu sprechen, wenn man in diesem rein administrative und planerische Aufgaben übernimmt, bei denen kein Deliverable für deinen Kunden entsteht. Gibt es Aufgaben für das Team: dann ist es ein regulärer Sprint, eben Sprint 1. Unser Deliverable, unser Ergebnis, ist beispielsweise die funktionierende Entwicklungsumgebung, ein Teil der Dokumentation und wahrscheinlich erste kleine Tasks, die einen sichtbaren Mehrwert für den Kunden erzeugen. Wer seinen ersten Sprint aber gerne bei null anfangen möchte zu zählen, kann das tun, solange ein Deliverable entsteht. Wir Informatiker sind es ja gewöhnt bei null anzufangen zu zählen ;). Trotzdem bleiben die Unsicherheiten: wieviel gehört in so einen ersten Sprint? Die Antwort klingt fast zu einfach: das was nötig ist und das was möglich ist.

Der erste Sprint

Ohne eine Velocity oder die Erfahrung vorhergehender Sprints und was man sich zutrauen kann, muss man quasi zurück zu den Wurzeln und überlegen: was brauche ich, um zu starten und wieviel Zeit kostet mich das? Ein Beispiel: Alle Entwickler setzen beispielsweise einen Tag lang ihre Entwicklungsumgebung auf, werden x Tage eingewiesen in das Programmiermodell und -vorgehen (Know your tools, Server, wie delivern, Definition of Done, Definition of Ready und wie läuft die Code Review ab? Was sind die Programmierrichtlinien und wie sieht die Qualitätssicherung und Test aus?) und je nach Länge des Sprints: welche ersten Aufgaben können zeitlich dann noch absolviert werden? Im ersten Sprint ist es valide nicht zu viel einzuplanen, sondern erstmal tief zu stapeln. Eine Story nachzunominieren und nach Start des Sprints noch nachträglich mit einzufügen, ist zwar für „Scrum nach Lehrbuch“-Fans nicht valide, aber im ersten Sprint sicherlich verkraftbar. Wer beim ersten Schätzen unsicher ist, kann sich bei erfahreneren Entwicklern Hilfe suchen und sehr transparent schätzen. Also „laut denken“. Hilfreich kann es sein zusammenzutragen, wieviel unterschiedliche Technik dafür angefasst werden muss. Habe ich Änderungen in der Datenbank bzw. der Persistenz allgemein? Oder ist es nur Businesslogik? Muss ich nur Tests schreiben oder ein ganzes Test-Framework aufbauen (schließlich sind wir am Anfang). Falls erfahrene Entwickler nicht da sind oder die Schätzung zu unscharf wirkt, kann sogar erstmal eine ganz andere Schätzmethode mit weniger Kategorien verwendet werden wie T-Shirt-Sizes (Story-Größen S, M, L, XL). Generell gilt aber: was die Schätzgrößen bedeuten (also wie komplex beispielsweise 5 Story Points sind), bestimmt das Team. Dafür gibt es keine allgemeingültige Antwort, weswegen im ersten Sprint auch manchmal einfach das berühmte Bauchgefühl reicht. Bei so viel Unschärfe ist klar: in Sprint 1 kann man daneben liegen. Die Korrektur erfolgt mit der Erfahrung ab dem zweiten Sprint und hilft für die Zukunft.

Tipps für den zweiten Sprint

Die Story und die jeweilige Schätzung des ersten Sprints, sollte als Referenz herangezogen werden. Best Practice ist, sich eine Liste sortiert nach Story Points anzulegen, die als Referenz-Storys dienen. So bekommen alle in Zukunft ein Gefühl dafür, was beispielsweise 5 Story Points bedeuten, wie komplex sie sind und wie solche Storys ungefähr aussehen. Lag man daneben und hat länger als erwartet gebraucht, war die Aufgabe also komplexer, dann kann das bei der Erstellung der Referenz berücksichtigt und korrigiert werden.

Falls du noch mehr über den ersten Sprint erfahren möchtest, kannst du hier weiterlesen:
Official Scrum Guide (scrum.org)
Your first agile sprint: A survival guide (TechBeacon)
Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint… (scrum.org Blog)

 

Advertisements

Open Source und motivierte Studenten

By Axel & Alexander

Im Rahmen eines Jahresprojekts mit der Hochschule Harz wollen wir den Grundstein für ein Open-Source-Projekt legen.
Nach anfänglichen Startschwierigkeiten, die aus Zeitmangel herrührten, ging es dann am 28.09.2016 in den Räumlichkeiten der Hochschule nun endlich los. Wir fanden uns in Wernigerode zu unserem ersten Projekttreffen ein. Anwesend waren hierbei fünf hoch motivierte Studenten, der betreuende Dozent Herr Prof. Dr. Olaf Drögehorn, sowie Alexander Schreiner und ich, Axel Krüger, aus dem CIC Magdeburg.

Das Thema
In erster Linie ging es bei diesem Treffen um das Kennenlernen des Teams und die Erläuterung der eigentlichen Aufgabenstellung. Da sich über den Köpfen der Studierenden viele Fragezeichen ansammelten. Ohne jetzt zu tief ins Detail zu gehen ist es alles in allem ein sehr anspruchsvolles und nützliches Projekt nicht nur aus Sicht des CIC sondern auch für die Open Source Community im Bereich Home Automatisation.Es soll eine Abstraktionsebene geschaffen werden,
die es ermöglicht einen Smart Home Automatisierungs Server und die gekoppelten Devices zu steuern. Diese Ebene soll über eine REST Schnittstelle ansprechbar sein.

Die ersten Schritte
Es wurden Ideen und Technologien besprochen die für die Umsetzung nötig sein würden. Man konnte zusehens feststellen wie die Augen der Studierenden anfingen zugleich zu funkeln und zu weinen. Sie begriffen langsam was wir mit Herrn Drögehorn vorhatten und stellten fest, dass eine Menge Arbeit auf sie zu kommt. Also fingen wir erst einmal an die Aufgabenbereiche abzugrenzen. Als erstes ging es um die Analyse der Technologien, was brauchen wir wirklich? Weiter ging es mit dem Abstecken des Designs. Wie detalliert muss das Design der Schnittstelle sein wie hoch der Abstraktionsgrad des Designs? Zum Schluss beschlossen wir gemeinsam mit dem Team, dass bis zum Ende dieses Jahres ein fertiges Design der REST API und eine Projektstruktur, die sich die Studierenden selbst erarbeiten müssen, stehen sollte. Der Start der Implementierung wurde folglich auf den Anfang 2017 gelegt.

Das Eis brechen
Um die ersten Eindrücke zu verdauen, beschlossen wir dann alle gemeinsam zu Mittag zu essen. In der Mensa wurde dann noch viel gefachsimpelt und das Eis mit alten Anekdoten aus der Studienzeit gebrochen. Die Studierenden waren sichtlich erfreut darüber dass Alexander und ich uns bereit erklärt hatten, sie mit unserem Wissen aus dem Bereich Software Entwicklung, unseren Erfahrungen aus dem Projektmanagement, so wie unserem Vorwissen über mögliche Technologien zu unterstützen. Wir beantworteten danach noch einige Fragen zum CIC in Magdeburg und der allgemeinen Arbeit eines Softwareentwicklers bei uns im CIC. Natürlich wurden auch noch viele Fragen zum Jahresprojekt gestellt und auch nach bestem Wissen und Gewissen beantwortet. Am Ende dieses Ersten Treffen hatten sowohl wir als auch Herr Prof. Dr. Olaf Drögehorn einen positives Gefühl und verabschiedeten uns mit einem guten ersten Eindruck vor der Projektgruppe.

Da es uns zeitlich leider nicht möglich ist jede Woche den Studierenden einen Besuch abzustatten entschlossen wir uns dazu, die Treffen auf einen Tag im Monat zu begrenzen. Natürlich sind wir für die Studierenden jederzeit per Mail erreichbar und nehmen telefonisch an den wöchentlichen Meetings der Projektgruppe teil.

Das Projektteam von links nach rechts: Christin Voscort, Marcel Wemmer, Timo Schwan, Benjamin Brausse, Philipp Trenz, Prof. Dr. Olaf Drögehorn

Das Projektteam von links nach rechts: Christin Voscort, Marcel Wemmer, Timo Schwan, Benjamin Brausse, Philipp Trenz, Prof. Dr. Olaf Drögehorn

 

Der 2. Besuch
Am 19.10.2016 starten Alexander und ich in aller Frühe um 8 Uhr zu unserem zweiten Besuch in Wernigerode. Die Studenten waren in den letzten Wochen damit beschäftigt ein Lastenheft auszuarbeiten.

Wir besprachen an diesem Tag das komplette Lastenheft. Was war schlecht ausgedrückt, was bedurfte weiterer Konkretisierung, wo muss mehr ins Detail gegangen werden und wo weniger?
Nachdem diese Thematik abgearbeitet wurde, ging es ans eingemachte. Wir wollten natürlich wissen inwieweit sich mit den Technologien und den aufgedeckten Problemen in den letzten Wochen beschäftigt wurde. Jeder Student wurde angehalten uns kurz zu erläutern, was er getan hat und ob noch Fragen zu diesem Thema offen waren. Ein großes Problem war das Verständnis von REST. Es fiel nicht allen leicht diesen Architekturstil direkt zu fassen und zu verinnerlichen. Dort konnten wir dann direkt aushelfen und etwas Licht ins Dunkel bringen. Nach einem gemütlichen Mittagessen mit Burger und Kartoffelspalten wurden noch einige kleinere Fragen besprochen.

Das Teamlogo

Logo der Projektgruppe

 

1. Fazit

Die Studenten machten einen sehr interessierten und engagierten Eindruck. In einigen Gesprächen war herauszuhören, dass sie diesen doch sehr komplexen und praktischen Ansatz begrüßen und auch sehen, dass es einen späteren Nutzen für sie hat. Sowohl Alexander als auch ich hatten nach diesem zweiten Tag den Eindruck, dass langsam aber sicher die Aufgabe und auch die Art und Weise der späteren Implementierung verstanden wurden. Wir sind sehr auf das weitere Voranschreiten des Projekts gespannt.

 

Meine Erfahrungen aus dem Praktikum bei IBM

by Jingyi

— Chance und Challenge

Ich bin eine Masterstudentin der Informatik und stehe kurz vor meinem Abschluss. Ich habe eine geeignete Praktikumsstelle im Betrieb gesucht, um fachliche Erfahrungen zu sammeln. Im CIC habe ich diese Chance erhalten!

Arbeiten im Projekt

Nach zwei Tagen mit On-Boarding-Kursen fing mein Praktikum als Java-Entwicklerin richtig an. Am ersten Tag habe ich schon die Freundlichkeit meiner Kollegen zu schätzen gelernt. Ich arbeite in einem Team, bestehend aus 7 Leuten.
Wir arbeiten in unserem Team sehr selbständig. Trotzdem tauschen wir uns ständig aus, denn wir gehen agil vor! Mithilfe dieser Methode arbeiten wir in einer flachen Hierarchie an den Lösungen für unsere Aufgaben und an deren Umsetzung. Während dieses Prozesses werden Zwischenergebnisse laufend geprüft und die Arbeitsweise angepasst. Ich selbst kann schnell das Ergebnis meiner Arbeit sehen und anderen zeigen. Das macht mich zufrieden und zuversichtlich. Ein weiteres Merkmal agiler Arbeitsweisen ist die Transparenz: Jedes Teammitglied weiß, was der andere im Team im Moment macht und welchen Stand die laufenden Projekte haben. Durch tägliche Scrum-Meetings und die zweiwöchigen Sprint-Meetings, haben wir die Chance, uns stetig über die Arbeit und untereinander mit Ideen auszutauschen.

Das Leben im CIC

Was ich sehr schön finde, ist, dass das Arbeitsklima im CIC total entspannt und freundlich ist. Die Arbeitszeit kann man sich relativ flexibel nach Vereinbarung einteilen. Obwohl es keine Kantine gibt, hat man viel Auswahl an Mittagsangeboten in der Nähe.
Als CIC-Mitarbeiter hat man auch die Möglichkeit, ständig kostenfrei an betriebsintern angebotenen Fortbildungskursen, wie z.B. die Java-Master-Class, teilzunehmen.

Ich habe viel in meinem Praktikum gelernt. Die wichtigste Fähigkeit ist, sich neues Wissen selber anzueignen. Weil es sehr häufig passiert, dass neue Aufgaben in einen ganz neuen Bereich fallen, mit dem du vorher noch nicht in Kontakt gekommen bist. Natürlich wird dieser Prozess durch die Hilfe von Anderen enorm erleichtert.
Des Weiteren ist es hilfreich, dass man immer, wenn man Fragen hat, mit seinem Betreuer sprechen kann. Und Sie reagieren schnell. Vielen Dank dafür!

Mein Fazit

Zusammenfassend betrachtet ist das Praktikum im CIC Chance und Challenge zugleich. Während meines Praktikums konnte ich gut meine Teamfähigkeit verbessern. Ich habe gelernt, sorgfältig die Ansichten meiner Kollegen anzuhören und ohne Angst meine Kommentare oder Vorschläge zu sagen. In der Tat waren meine Kollegen mir während des gesamten Praktikums eine sehr große Hilfe. Ich bin sehr glücklich, mein Praktikum im CIC gemacht zu haben. 🙂

Job des Monats – Senior Softwareentwickler Java/ JavaEE

In unserer neuen Rubrik ‚Job des Monats‘ stellen wir euch ab sofort einmal im Monat CIC Mitarbeiter und ihre aktuelle Jobrolle vor. Auf unserer Homepage findet ihr passend dazu aktuelle Stellenangebote an unseren verschiedenen Standorten. – Vielleicht ist ja auch euer Traumjob dabei?

Blogredaktion: Kannst du uns kurz etwas zu deiner Person sagen?
Martin: Hallo, mein Name ist Martin Eichardt und ich bin Softwareentwickler hier im Center. Mit der Programmierung und Entwicklung von Software beschäftige ich mich schon seit vielen Jahren. Dabei habe ich im Lauf der Zeit verschiedene Frameworks und Programmiersprachen kennengelernt. Aktuell arbeite ich überwiegend mit Java im Enterprise Umfeld. Ich entwickle dabei Webanwendungen für den Bereich Automotive.

Blogredaktion: Wie lange bist du bereits im Center und was hat dich bewogen, dich hier zu bewerben?
Martin: Im Center bin ich seit Januar 2014 und habe in dieser Zeit verschiedenste Projekte begleitet. Dabei reicht die Bandbreite von Datenbankanalyse-Projekten bis hin zur Entwicklung von Webapplikationen.
Einerseits ist es mir wichtig neue Technologien, Methoden und Prozesse kennenzulernen sowie damit zu arbeiten und andererseits möchte ich mich auch persönlich weiterentwickeln. Genau das war der Grund mich vor über 2 Jahren hier im Center zu bewerben.

Blogredaktion: Eine der Rollen hier im Center ist die des Senior Softwareentwickler Java/ JavaEE. Welche Sichtweise hast du zu dieser Rolle?
Martin: Ich denke für die Rolle eines Senior Softwareentwickler ist ein gewisses Maß an Lebens- und Berufserfahrung notwendig. Zum einen muss ein Senior Softwareentwickler natürlich Konzepte und Methoden kennen und diese auch anwenden können. Zum anderen muss er auch das Handwerkszeug, wie Programmiersprachen und zugehörige Frameworks, aber auch die Tools beherrschen. In Zeiten von agiler Softwareentwicklung und Prozessmodellen, wie Scrum und Kanban, gibt es zwar nicht mehr die starke Unterteilung, aber innerhalb des Teams bildet sich trotzdem eine gewisse Hierarchie ab. Somit gibt es auch immer Schlüsselpositionen bzw. Lead Entwickler, welche das Team unterstützen und voran bringen.

Blogredaktion: Was muss man an Kenntnissen mitbringen, um die Rolle eines Senior Softwareentwicklers ausführen zu können?
Martin: Ein Senior Softwareentwickler hat langjährige Erfahrungen auf einem Spezialgebiet oder einen umfangreichen Wissensschatz in mehreren Anwendungsgebieten. Neben den technischen Skills bringt ein Senior Softwareentwickler, meiner Meinung nach, auch  Projektleitungserfahrungen mit. Damit sind auch soziale Kompetenzen wichtig.
Eine entscheidende Fähigkeit des Senior Softwareentwicklers ist für mich ebenfalls das Weitergeben von Wissen. Dabei sollte er aber auf Augenhöhe zu seinen Teamkollegen agieren und allen Teamkollegen die Möglichkeit der Weiterentwicklung geben.

Blogredaktion: Was gehört zu den täglichen Aufgaben und Verantwortungen, die diese Rolle mit sich bringt?
Martin: Das schwierige an dieser Rolle ist, dass es eigentlich keine feste Definition dafür gibt. Diese Titel werden von Firma zu Firma unterschiedlich oder gar nicht vergeben. Im Grunde genommen leistet der Senior Softwareentwickler die gleiche operative Arbeit in Projekten wie alle anderen Entwickler auch. Darüber hinaus hat er aber Einfluss auf Entscheidungen und ist in der Lage beim Finden von Lösungsvarianten bzw. Lösungsstrategien zu beraten. Eine zusätzliche Verantwortung sehe ich in der fachlichen Weiterbildung von weniger erfahrenen Softwareentwicklern im Team.

Blogredaktion: Welche Möglichkeiten gibt es hier im Center, die dir eine Weiterentwicklung in dieser Rolle ermöglicht? Hast du eventuell schon einige wahrgenommen?
Martin: Hier im Center ist eine Vielzahl an  Optionen vorhanden, um sich weiterzubilden. Dabei gibt es die Möglichkeit auf online Kurse bis hin zu Klassenraumschulungen zuzugreifen, um neue technische Qualifikationen zu erlangen oder vorhandenes Wissen zu vertiefen. Zusätzlich kann auch auf externe Angebote zugegriffen werden. So habe ich zuletzt eine Zertifizierung für die Programmiersprache Java abgeschlossen. Und das nächste Schulungsangebot wartet bereits auf mich. Im September geht es nach Hamburg zu einem Wissenstransfer zum Thema „cognitive solution on cloud“.

Von Workshops, Zertifikaten und neuen Rollen

By Jasmin

Ihr habt schon lange nichts mehr von mir gehört, oder? Irgendwie hat es sich nie ergeben, euch zu erzählen, in welchem neuen Projekt ich bin und was mich zu meiner jetzigen Rolle geführt hat. Es war eigentlich ganz einfach. Nachdem mein App-Entwicklungsprojekt zu Ende ging, habe ich mich neu orientieren wollen. Ich bemerkte schon während meines ersten Projekts, dass ich gerne Dinge organisiere, Strukturen schaffen möchte und prozessvernarrt bin. 😀 Also lag es auf der Hand, dass mich meine Interessen zum Project Management Office (PMO) führen. Ich unterstütze nun in einem „Cloud Managed Services“-Projekt und versuche Prozesse in das stetig wachsende Team zu bringen. 😉 Je größer ein Projekt ist, desto notwendiger werden Prozesse. Da kann der Projektleiter nicht die Zeit aufwenden und jedem neuen Kollegen z. B. Zugänge einrichten, durch die Projektdokumentation führen oder erklären wie das Ticketmanagementsystem funktioniert. Das übernehme ich dann und unterstütze den Project Lead außerdem in Data Security & Privacy-Themen und mit Dokumentationen.

Als PMO versuche ich mich natürlich auch weiterzubilden und hatte das Vergnügen an einer ITIL-Zertifizierung teilzunehmen. Die IT Infrastructure Library (ITIL) ist ein Referenzrahmen zum strukturierten Ansatz von IT-Service Management. Die Wichtigkeit dieser Strukturierung erkennend, treibt IBM das Framework als Entwickler, Reviewer und Nutzer weiter. Ich konnte meine Kenntnisse aus dem Training gleich anwenden und unser vom Projekt genutztes Ticketmanagementsystem auf ITIL-Prozesse umstellen. Dazu gehören beispielsweise Incident Mangement und Problem Management.

Doch das war nicht alles in den letzten Monaten. Da das Center in Sachen Diversity viele Veranstaltungen organisiert, konnten einige Kolleginnen als erste Versuchsgruppe an dem Workshop „Taking the Stage“ teilnehmen. Wir bekommen Soft Skills zum Thema „Präsentation der eigenen Person“ vermittelt und können uns Leadership-Qualitäten erarbeiten. Wir haben auf jeden Fall viel Spaß in dem Training, ändern die Perspektive, analysieren Situationen und festigen unsere neu erworbenen Skills mit diversen Übungen, die uns aus unserer Comfort Zone locken. 😉 Es wird also nie langweilig bei uns.

In dem Sinne verabschiede ich mich und melde mich wieder, wenn es neue Updates gibt.

How to become an IBMer: Der Berufsstart mit der Masterclass

By Elisabeth

Wie ihr meinem ersten Beitrag bereits entnehmen konntet, bin ich letztes Jahr durch die Masterclass ins Unternehmen gekommen. Dieses Jahr wird wieder eine „Softwareentwicklung Java Enterprise Applications“Masterclass stattfinden. Deshalb würde ich euch gern an meinen Erfahrungen teilhaben lassen. Viel Spaß. 😉

Letztes Jahr im Oktober war es im Center mal wieder so weit, eine Gruppe Neueinsteiger wurde willkommen geheißen. Viele von uns kamen frisch von der Uni und hatten noch keine Berufserfahrung gesammelt. Deshalb wartete auf uns etwas ganz Besonderes: die Masterclass, die uns den Start als IBMer erleichtern sollte.

Das inzwischen bewährte Konzept der Masterclass richtet sich an Absolventen wie uns. Ziel ist es, vor dem Start in die Projektarbeit die nötigen Softskills sowie einige technische Facetten des IT-Entwicklerjobs zu vermitteln.

In letztem Jahr stand die Masterclass unter dem Thema „Softwareentwicklung Java Enterprise Applications“. Nach einigen Startschwierigkeiten (wie Laptops auf Weltreise oder fehlenden Credentials) hieß das für etwa zwanzig Neu-IBMer verschiedenster IT-naher Studienrichtungen learning learning learning! Fünf Wochen lang hatten wir die Möglichkeit, Schulungen zu IT-Themen wie „relationale Datenbanken/DB2“, „Java SE 6 Programming Fundamentals“ und „Java Server Faces“ vor allem in Form von Klassenraumunterricht zu absolvieren, der Englischauffrischungskurs mit dem rumänischen Trainer war inklusive.

Zusätzlich konnten grundlegende Softskill- und Prozessschulungen im Klassenraum oder als eLearning  besucht werden, um das blaue Gefühl und Selbstverständnis der New Hires zu stärken.

Die Masterclass bot uns mit ihrem ausgewogenen Mix aus Theorie und Praxis sowie Fachthemen und Sozialkompetenzen die Möglichkeit, erste Eindrücke in unserem Leben als IBMer zu sammeln und gleichzeitig unseren CV mit einigen Kernkompetenzen zu füllen. Außerdem erlaubten uns diverse Pausenkaffees und Teamarbeiten einander kennen zu lernen und schweißten uns als „Masterclass Oktober 2015“ zusammen. Dieser Start als Team machte uns den Berufseinstieg besonders angenehm. So gilt den Kollegen der Masterclass bei Treffen auf dem Flur immer ein besonders freundliches Lächeln.