Scrum4Schools an der Hochschule München: Auch Professoren lernen immer wieder dazu

Es sind noch gute zehn Minuten bis zur nächsten Seminarstunde von Prof. Holger Günzels Kurs “Agile Management for Entrepreneurs”. Rund die Hälfte der Studierenden sitzt bereits in verschiedenen Ecken des großzügigen Hörsaals, der wegen der flexiblen Gestaltungsmöglichkeiten auch „Lehrraum der Zukunft“ genannt wird. Die Studierenden diskutieren angeregt und geben ihren Präsentationenden letzten Schliff für das gleich stattfindende Review der letzten Studienarbeitsiteration. Die Gruppe arbeitet in diesem Semester mit Scrum4Schools.

Woche 3 – Verbessern und optimieren

Arbeiten mit dem Taskboard – Transparenz entsteht

Mittlerweile befinden wir uns in der dritten Woche des wöchentlich stattfindenden Seminars. In der letzten Woche hat der erste Sprintwechsel, bestehend aus Review, Retrospektive und anschließendem Planning stattgefunden. Diesmal wirkt alles schon etwas eingespielter und die Präsentationen der inhaltlichen Konzepte der einzelnen Studierendenteams nehmen Gestalt an. Jedes Team hat im Review 10 Minuten Zeit, um seine aktuellen Ergebnisse zu präsentieren und Feedback einzuholen.
Die meisten Teams zeigen zum Start der Präsentation ihr Taskboard. Auf dem Taskboard ist auf einen Blick transparent, an welchen User Stories (=Teillieferungen des fertigen Produkts) das Team in der vergangenen Woche gearbeitet hat und welcher Studierende welchen Task (= Aufgabe) dabei übernommen hat. Um auch zwischen den Seminarstunden den Arbeitsfortschritt zu sehen, nutzen die meisten Gruppen ein digitales Board. Dazu bietet sich beispielsweise das frei verfügbare Programm Trello an.

Kontinuierliches Feedback statt Stress vor der Abgabe bringt bessere Ergebnisse

Die Studierenden aus den anderen Teams füllen während jeder Kurzpräsentation der verschiedenen Gruppen den im ersten Termin gemeinsam erstellten Feedbackbogen aus. Auch Prof. Günzel gibt nach jeder Kurzpräsentation eine Rückmeldung, worauf die jeweilige Gruppe sich noch stärker fokussieren kann – allerdings haben die meisten Teams die Aufgabenstellung richtig verstanden und arbeiten in die richtige Richtung. Bei manchen Teams gibt es mehr Feedback von Mitstudierenden und von Prof. Günzel. Sie sind bei der Bearbeitung der Aufgabenstellung nicht konkret genug geworden und müssen ihr Konzept nochmals überarbeiten. Prof. Günzel ist begeistert von dem Ansatz: „Normalerweise kommen die Studierenden – wenn überhaupt – wenige Tage vor der Abgabe zu mir, um sich Feedback für ihre Arbeiten einzuholen. Dann ist es meistens schon viel zu spät. Über die Arbeit mit Scrum gibt es kontinuierliches Feedback. Und das nicht nur von mir, sondern auch von anderen Studierenden.“

Verbesserung des Prozesses – wie ein effizienteres Review aussehen kann

Das Review und die anschließende Diskussion nach jedem Team haben länger gedauert als geplant. Wertvolle Zeit ging auch durch das Umstecken der Laptops zwischen den einzelnen Präsentationen verloren. Die Seminarstunde ist inzwischen fast zu Ende und Prof. Günzel bittet die Teams, die letzten fünf Minuten für eine kurze Retrospektive zu nutzen. Die Teams analysieren in der Retrospektive, wie sie ihre Zusammenarbeit in der kommenden Woche verbessern können. Er selbst reflektiert, was im Review passiert ist. Die Präsentationen, die die einzelnen Teams gezeigt haben, erinnerten ihn eher an klassische Seminarvorträge. Es gab viele PowerPoint-Folien und zum Teil waren die Folien auch noch nicht ganz fertig. Prof Günzel erinnert sich an das Ziel des Reviews: Das Einholen von Feedback zu abgeschlossenen Teilergebnissen.
Er hat eine Idee, wie er in der kommenden Woche das Review besser gestalten kann, und gibt seinen Studierenden drei Punkte mit:

  1. Im nächsten Review dürfen nur noch abgeschlossene User Stories vorgestellt werden.
  2. Pro User Story dürfen maximal zwei Folien erstellt werden, die die Studierenden ausgedruckt mitbringen und zu Beginn der Stunde an der Wand befestigen. Im Review geht dann die gesamte Seminargruppe von Teamwand zu Teamwand.
  3. Die Studierenden schreiben ihr Feedback zu den einzelnen Präsentationen auf Post-its und geben sie den einzelnen Gruppen mit.

Prof. Günzel erhofft sich dadurch einen reibungsloseren Ablauf des Reviews. Es geht ihm aber vielmehr darum, dass ein kommunikativerer Austausch in der Gruppe entsteht und die Studierenden sich gegenseitig mehr Feedback geben. Er ist gespannt, ob es funktionieren wird.
Die Erlebnisse von Prof. Günzel in seiner Reviewstunde zeigen, dass es kein Patentrezept dafür gibt, wie man Scrum4Schools am besten einführen sollte. Das Rahmenwerk muss immer auf den jeweiligen Kontext wie beispielsweise die Lernaufgabe und die zur Verfügung stehende Zeit angepasst werden. Dabei ist jeder gefragt. Und es braucht immer eine gewisse Zeit, bis eine Gruppe den optimalen Modus für sich gefunden hat. Grundvoraussetzung dafür ist die Bereitschaft, neue Dinge auszuprobieren und den eigenen Prozess kontinuierlich zu verbessern.

Scrum bei alpha-board (Teil 2): Scheitern spart Geld

Inzwischen sind einige Wochen in meinem Projekt bei der alpha-board GmbH, einem Dienstleister für agile Hardware-Entwicklung,  in Berlin vergangen und bis jetzt haben wir beinahe jede Woche geliefert. Zuerst konstruierten wir einen Prototyp, um technische Risiken zu minimieren. Dieser war zwar alles andere als hübsch, aber nun war geklärt: Die kritische Funktionalität ist realisierbar. Im nächsten Prototyp zogen wir für eine bessere Marktfähigkeit die Constraints der Funktionalität an. Im dritten Sprint, letzte Woche, wollte mein Team eine vorgesehene Heizeinheit mit einer eigens entwickelten Induktionsspule realisieren. Leider blieb die erhoffte Wirkung aus. Der Sprint war gnadenlos gescheitert. Und jetzt?
Na ist doch super! In keinem anderen Sprint wurde wohl so viel Geld eingespart wie in diesem. “Fail fast” nennen das die Agilisten. Boris schreibt zu dieser Thematik (Gloger 2014): „Das Produkt muss durch die gelieferten Produktteile beweisen, dass es wert ist weiterentwickelt zu werden.“ Entwickeln um jeden Preis, das ist etwas für Anforderungsingenieure ohne Kostendruck, nicht für Pragmatiker.

Anforderungen komplett unklar? Perfekt!

Problematisch wird es erst, wenn der Kunde schon zu viel in die Anforderungserhebung investiert hat. Jede Menge Geld ist verbraucht und vermeintlich alle Daten für ein Produkt sind schon verfügbar. Scheitert nun ein Sprint, sprich eine Anforderung ist nicht lieferbar, ist viel Geld verloren, weil darauf aufbauende Anforderungen umsonst spezifiziert wurden.
Das logische Resultat für viele Kunden ist: Jemand muss schuld sein. Wahrscheinlich ein Business Analyst, ein Ingenieur, ein Manager oder alle drei. Je nach verlorenem Betrag wird mit den entsprechenden Personen dann verfahren, ein Change Manager tritt auf den Plan und der Planungsprozess für zukünftige Projekte wird intensiviert. Das kostet zusätzlich Geld.
Die angenehmsten Projekte sind für mich – unter anderem aus diesem Grund – Projekte der Kategorie „ist gerade reingekommen”, “es drängt“ und „Produktanforderungen sind unklar“, denn sie implizieren: Es gibt keine vorangegangene Planung und damit viel weniger zu leistende Überzeugungsarbeit, falls etwas Unvorhergesehenes passiert. Ich behaupte außerdem, dass diese Konstellation den Entwicklern eine höhere Wahrscheinlichkeit bietet, ein besseres Produkt zu entwickeln, als es der Kunde erwartet.

DCIM100MEDIADJI_0024.JPG

Viktor Hanacek, picjumbo

Eine Hypothese

Bei unserem aktuellen Projekt waren die genauen Anforderungen nicht weiter spezifiziert. Das ist besser? Ja, da nur dann Forderungen des Kunden übertroffen werden können. Lassen Sie mich das näher erklären. Henry Ford wird der Satz zugeschrieben: “If I had asked people what they wanted, they would have said faster horses.” Er impliziert damit, dass ein Entwickler immer besser weiß, was der Kunde braucht, als es der Kunde artikulieren könnte. Dieses Denken hat sich aber nie wirklich etabliert. Dagegen werden so gut wie alle Anforderungen vor der eigentlichen Entwicklung vom internen oder externen Kunden spezifiziert.
Viele Daten existieren damit bereits und verhindern Innovation. Boris schreib dazu (Gloger 2014): „[…] Dadurch treibt das Produkt in eine vorgegebene Richtung, obwohl die Spezialisten im Team eine besser geeignete Lösung anbieten könnten.” Darüber hinaus haben die spezifizierten Daten mit dem schlussendlichen Produkt ungefähr so viel zu tun wie die sprechende Klammer mit dem eigentlichen Office-Produkt: Ob der Anwender sie wirklich braucht, ist eine Hypothese und zwar eine sehr teure. Auch im agilen Umfeld arbeitet man mit Hypothesen, allerdings nur – wie im 1. Teil angesprochen -, um sie zeitnah zu beweisen oder zu widerlegen.
 

Das Ziel ist das Endprodukt

Mein aktuelles Projekt beim Leiterplatten-Entwickler alpha-board GmbH hat mich gelehrt: Für Scrum macht es keinen Unterschied, ob man Hardware oder Software entwickelt. Denn der ideale Zeitpunkt der Anforderungsspezifikation ist immer gleich: Möglichst kurzfristig vor der Umsetzung. Bei unserem Produkt handelt es sich um eine Neuentwicklung, die es so auf dem Markt noch nicht gibt und per Crowdfunding finanziert wird.
Die Kunden investieren also in eine Vision und nicht in ein Pflichtenheft mit detaillierten Anforderungen. Im Umkehrschluss bedeutet das: Für eine Vision bezahlt zu werden bedeutet, dass man Anforderungen erst konkretisieren muss, wenn man sie tatsächlich braucht. Der Zwang, vorher alles wissen zu müssen, ist minimal. Mein Team hat sich schnell an den Umstand gewöhnt, dass sein bearbeitbares Backlog nur etwas größer ist als der aktuelle Sprint. Und warum? Es hatte keine andere Möglichkeit. Auch Mike Cohn hat User Stories nicht aus einem Idealgedanken heraus verwendet, sondern weil er einfach nicht mehr Zeit bekommen hatte, um alles detailliert zu planen (Cohn 2009).
Aber gar nicht zu planen, ist unrealistisch. Beispielsweise war mein Team regelmäßig versucht, nur auf den nächsten Prototyp hin zu entwickeln und nicht auf das eigentliche Endprodukt. Das regulierte sich glücklicherweise schnell selbst, denn unser Product Owner pochte immer wieder auf die Erfüllung der eigentlichen Vision. Dass dies nicht immer eine schwierige Lösung bedeuten muss, zeigt das anfangs beschriebene Induktionsspulen-Problem: Für die Heizeinheit hat es schlussendlich auch eine handelsübliche Heizspule getan.
In diesem Sinne, euer Marcus.
Quellen:
Cohn, M. (2009). User Stories Applied. Boston, MA: Pearson Education, Inc.
Gloger, B. (2014). Wie schätzt man in agilen Projekten. München: Carl Hanser Verlag.

Scrum bei alpha-board (Teil 1): Wir bauen uns einen Kunden

Ankunft Alexanderplatz im Herzen von Berlin. Im aktuellen Projekt geht es um das Schleifen der agilen Vorgehensweise bei einem Dienstleister für agile Hardware-Entwicklung – der alpha-board gmbh. Kennzeichnend für die Auftragsentwicklung von alpha-board ist ein stets hoher Termindruck, da Produktideen innerhalb kürzester Zeit umgesetzt werden müssen. Mir geht es bei alpha-board darum, Kinderkrankheiten zu beseitigen und mit dem Team gemeinsam neue Best Practices für die Branche  zu entwickeln. In dieser kleinen Blogreihe möchte ich davon erzählen und gerne auch Anregungen für Ihr eigenes agiles Projekt geben. In erster Linie wird es um das Generieren von und das Umgehen mit agilen Anforderungen gehen.

Startbedingungen

Die Voraussetzungen für Scrum bei alpha-board sind gut: Eigenverantwortlich und cross-funktional arbeitende Ingenieure, die Produkte von Anfang bis Ende entwickeln können, ein Prototypen-Labor, in dem designte Leiterplatten innerhalb von Stunden per Fräßtechnik erstellt werden können, eine Geschäftsleitung, die mir jeden gewünschten Ingenieur von anderen Projekten freistellt und eine komplexe Hardware-Neuentwicklung.
Das erfordert kurze Feedback-Zyklen, was mich in der Rolle als ScrumMaster besonders freut. Denn unser Sprint wird lediglich eine Arbeitswoche dauern und jeweils einen Prototyp liefern. Das ist für viele Hardwareentwickler Utopie, aber in der Software-Branche war das vor ca. 20 Jahren ähnlich. Der Vorteil kurzer Sprints: Je kürzer die Iteration, desto agiler wird die Neuentwicklung an sich und desto schneller können wir User-Feedback erhalten. Zeitgleich erzeugen wir als Team selbst schnelles Methodenfeedback, das uns hilft, unsere Vorgehensweise zu verfeinern und Hindernisse schneller aufzudecken.

Ohne Produkt kein Nutzer, also bauen wir uns einen.

Wir sitzen im ersten Backlog Refinement, allerdings schreiben wir heute keine einzige User Story. Darum geht es uns auch nicht. Wir schreiben Personas. Unser Refinement könnte man heute auch einen “Persona Workshop“ nennen. Was ist eine Persona?
Die Kurzantwort: Personas sind fiktive Charaktere mit allem, was dazu gehört. Zum Beispiel:

Was haben die beiden Charaktere gemeinsam? Sie haben beide einen Namen, ein gewisses Alter, authentische Charaktereigenschaften und ein produktrelevantes Nutzungsverhalten. Beide Personas sind also potenzielle Endanwender für unser zu entwickelndes Produkt. Mir geht es primär nicht darum, wie realitätsnah die beiden Personas tatsächlich sind, sondern wer die Personas baut: Das tun nämlich alle Abteilungen, die an der Produktentwicklung beteiligt sind, inklusive Entwicklungsteam. Bei alpha-board haben Team, Vertrieb und Management gemeinsam diese und zwei weitere Personas gebaut.

Aber warum eine Persona?

Namen erfinden, Profilbilder malen, das ist ein Anwender-Ratespiel. Man könnte meinen, es passt so gar nicht zur Agilität, die doch das empirische Vorgehen betont. Aber um empirisch vorgehen zu können, müssen wir bei mangelnder Informationslage (im komplexen Umfeld also quasi immer), zuerst verhandelbare Hypothesen aufstellen. Bei der Anforderungsgenerierung sind das User Stories, bei Endanwender-Gruppen bzw. einer Anwenderrolle sind es die besagten Personas. Ziel der Hypothese ist es immer, bewiesen oder widerlegt zu werden. Ein zweifellos gutes Mittel dafür ist die klassische Nutzeranalyse. In meinem aktuellen Projekt entwickeln wir Personas nicht nur, um Produktanforderungen zu verfeinern, sondern um in den Köpfen aller Teammitglieder Bilder von einem User entstehen zu lassen, für den das bestimmte Feature entwickelt werden soll.

Wir entwickeln nutzerorientiert

In der Konsequenz agilen Vorgehens entwickelt man idealerweise primär entlang des Endanwender und nur sekundär oder gar nicht entlang des eigentlichen Lastenhefts. Ein weiterer Bonus: Aus einer Persona erschließt sich, warum das Produkt gebraucht wird. In einem aktuellen Fall haben wir eine Produktidee verworfen, weil wir keine realistische Persona dafür bauen konnten. Wo es keine sinnvolle Hypothese gibt, ist ein Beweis hinfällig. Das Produkt muss entweder besser verstanden oder eingestellt werden. Dieses Vorgehen ist nicht nur empirisch, sondern auch nutzerorientiert.
In diesem Sinne, euer Marcus.

Agile e-commerce: 44 Bricks is building success through focus

Agile @ e-commerce companies – possible?
Of course it is! 44 Bricks, one of the biggest online shops in re-selling LEGO® bricks all over the world, is doing it. They started to go agile and celebrate new records in revenue and employer satisfaction each month. Richard and Dennis, the two 28 and 29-year-old self-made CEOs, asked me for help: „Lisa, you do „that” Scrum. Can you help us to be more focused? We have recognized that it is hard for us to finish all the things on our plate. Furthermore, we would like to open new market opportunities and think more strategic, which is almost impossible because of all the tasks we are involved in.“ Yes, great challenge, thank you!

What are they doing?

During the last five years, over 2 million LEGO® bricks per year were handled and sold by six employees and two CEOs in a 200m² storage space. Each day they receive about 40 orders and ship out boxes filled with used and new items to LEGO® fans around the world. They sort, select, sometimes wash, add them to their shop. They pick and pack them from their inventory system consisting of 12 walls with boxes and drawers of different sizes filled with over 30.000 different lots in different shapes, colors and sizes. Beside this product-related workflow they need to purchase products and supplies, maintain their high customer support standards and deal with the usual overhead that companies of their size are confronted with.

They are never done, aren’t they?

Dinner time. I met Richard and Dennis at their favorite Italian restaurant. The whole table was packed with post-its, scribbles and printed excel sheets. The first thing the two CEOs recognized when we started to talk about what „that Scrum“ actually means, was that they do not have a tangible product that is considered „done“ at some point of time. The flow of incoming orders never ends. After the first course they had understood that as a service provider their customer always is the center of their workflow. In their business, „Done” actually is the point in time when the customer receives the order and gives positive feedback. Based on that concrete thought, Richard and Dennis were able to see their service as a product. So the question, why a customer should prefer their shop to one of their 9.000 competitors, was easy to answer.

Make it concrete and make it emotional!

„Whenever you start a LEGO project you have to step by at 44 Bricks … they simply have everything in their shop and the service is outstanding.“ That was a perspective I loved to work with. This customers voice was my keyword to continue with. Which feedback do you receive from your customers and what would make them happy? How do you define „outstanding service”? What do customers, planning big LEGO projects, think? Where do they order and how? What needs to happen so they end up in your store? How can you see that the customer is satisfied? What is the next little step that brings you closer to your vision?

Make work visible!

I explained the values of Scrum and led them through a quite usual client reaction process, starting from „this is not going to work at our company“, via „but I am the boss, I need to tell them what to do“ to „Don’t I???“. The main course was served. We looked at each single step of the workflow and related them to one of three working teams: the „Butchers” (who sort incoming boxes by categories and wash them), the „Packers” (who add the parts to the shop and pack the incoming orders) and the team of „Pinky and Brain” (who do customer service, accounting, strategic planning and supply acquisition). Guess to which team Richard and Dennis belong to? Each team has its very own tasks, besides those there are general tasks that everybody can do.
Lisa_Besprechung
As the dessert was served, we tried to figure out a reasonable and transparent way to prioritize all tasks. We came up with the idea of a monthly goal that points out the focus, e.g. add 10% of the stock to the shop, or increase revenue by 10%, or the maximum lead time for incoming orders is reduced by 50%. According to those focus goals, team „Pinky and Brain“ would be able to break down and formulate daily goals on which all open tasks can be prioritized by their impact and necessity to achieve it.

Consider resistance as chance

Italians usually have Espresso after dinner, we had two of them. „How about buying supplies like stamps or office stationery, if they are not relevant for the focus goal?“, one of the CEOs asked. Well, these tasks will inevitably move upwards the priority line because if you run out of those essential things, you can neither reach your daily goal nor your focus goal nor your vision because you cannot dispatch anything anymore. „So we have to walk around and collect all tasks?“, they asked. How about asking your teams to collect all necessary tasks each day; everything they see, everything they think that could be relevant. „How do all of them know what is planned for each day?“ It would be great to find a way that makes synchronization possible for everybody. So they would know what is important and they could plan their working day together accordingly. Each team is responsible for finding a way to achieve their goal, for example with a daily Stand-up. „What if they don’t pull the tasks that are considered no fun?“, the CEOs were concerned. Let the teams deal with that question, they will find a way, when they understand why this very task is so essential for reaching the focus goal. If not, you can offer to help them finding a solution.

Every game needs rules

At the end of our dinner, the CEOs figured out that they are not going to do Scrum by the book. However, the first iteration of their Kanban-system was born. I sent Richard and Dennis home so they could slowly get accustomed to the idea of transparency, focus and self-organization. One week later, they invited all employees for a Friday evening beer, so they could share the current accounting numbers, the market situation as well as a future working model, called „that Scrum“. After answering all upcoming questions on their own (they owned the process, so I was only needed to stand in the back rear and nod), they invited all employees to try out the new working model within the next month.
Lisa_Board
Everybody was invited to give feedback to the board and establish their own rules, that could help them to be more successful:

After one month

Richard called me after one week of implementation and asked hysterically: “What do we do if we recognize that some employees do less than other members of the team?“ Well, I said, first of all we celebrate because we can see our progress and what is happening in our company! Yes, Scrum causes transparency and it’s a good thing. We value that something can be improved because that means we have potential to grow and get better. Besides that, you finally can do your job and lead your team to find their own solutions. Show them what you see and let them discuss, how they would like to handle it and what they would like to change within their team. “Hmm, okay“, and back he went in order to learn how to be a servant leader.
Thanks to these two innovative guys, I have learned some valuable lessons as well:

After one month Richard called me again via Skype with a smile on his face: “What do we do, if it is 3pm and there is nothing to do anymore, because the daily goal is achieved and also all the tasks below the first swim lane, from the idea box are done?“ Congratulations! You got to know Mrs Focus herself! Return to your teams, celebrate your success and ask them if they have a topic they would like to address or push forward. Furthermore, you can finally start thinking strategically again with Dennis, explore new business opportunities and come up with ideas how to serve your clients better.

And now?

44 Bricks is currently the most favorite shop around the world according to customer’s vote. They now design and sell their own t-shirt line and surprise their fans with funny scenes build by LEGO® bricks on their social network platforms. The two CEOs are currently working on important mergers with two international shops. Cheers!
Lisa_Lego

Inspired & Required – Wooga: Ansporn mit Feelgood-Spirit und Schlafkojen

Feelgood-Teams, ein eigener Unternehmens-Koch, Job-Ticket für die Öffis, Home-Office oder Ruhekojen: Dass es mittlerweile mehr braucht als nur geregelte Arbeitszeiten und 30 Urlaubstage, um qualifizierte Mitarbeiter bei der Stange zu halten, haben viele Unternehmen bereits gemerkt. Es passiert was in den Unternehmenskulturen. Bestehende Strukturen werden umgekrempelt, damit die Mitarbeiter motiviert zur Arbeit kommen.
In unserer Serie „Inspired & Required“ wollen wir Unternehmen vorstellen, die ein bisschen innovativer aufgestellt sind als andere und besonders ungewöhnliche Maßnahmen ergreifen, um auf diese Weise ihren Mitarbeitern zu helfen, ihren Job gut zu machen. Den Anfang machen wir heute mit Wooga (http://www.wooga.com/) aus Berlin. Die Softwareentwickler für Mobile Games erfinden und gestalten weltweit erfolgreiche Spielekonzepte für Handy, Facebook und Co. und bringen mehr als 250 Mitarbeiter aus 40 Nationen unter ein Dach.
Obwohl Wooga schon lange kein kleines Startup mehr ist, hat es sich die Strukturen eines solchen bewusst bewahrt. Denn das große Ganze setzt sich aus kleinen Game-Teams zusammen, die wiederum handeln können wie agile Startups. In jedem einzelnen organisieren und gestalten bis zu 10 Köpfe ein eigenes Projekt und treffen bis zum Schluss jede einzelne Entscheidung selbst. Seit zwei Jahren gibt es bereits ein Feelgood-Team im Unternehmen, das sich ganz besonders um Neuzugänge aus dem Ausland kümmert. Wooga hilft nicht nur bei der Integration ins Unternehmen, sondern greift auch bei mühsamen Behördengängen unter die Arme, genau wie bei der Wohnungssuche. So können Neuankömmlinge erst mal 6 Wochen in einer Übergangswohnung bleiben, die von Wooga organisiert und bezahlt wird. Denn: Je schneller der Mitarbeiter sich angekommen fühlt, desto schneller packt er auch konzentriert seine Arbeit an.
Ein weiteres wichtiges Thema ist die soziale Vernetzung der einzelnen Mitarbeiter. Regelmäßig werden Neuzugänge zum Pizzaessen mit dem Management-Team eingeladen, damit man sich kennenlernen kann. Beim monatlichen Mystery-Lunch beispielsweise wird ein Tisch immer von vier Leuten geteilt, die sonst nicht so viel miteinander zu tun haben. So schauen alle mal über den eigenen Tellerrand hinaus und bekommen einen Einblick in das, was die anderen eigentlich so machen. Dem Unternehmen ist zudem wichtig, auch langfristig mit der Konkurrenz mitzuhalten. Den Schlüssel dazu sieht Wooga in seinen Mitarbeitern und stellt jedem von ihnen jährlich ein großzügiges Weiterbildungsbudget zur Verfügung, das an zwei vollen Tagen im Jahr zur persönlichen Ausbildung genutzt werden kann.
Und das ist noch lange nicht alles: Um jederzeit fit für wichtige Entscheidungen zu bleiben, gibt es bei Wooga Ruhekojen, welche die Mitarbeiter für einen kurzen Powernap nutzen können, wenn das Gehirn mal nicht so arbeitet, wie es sollte. Und hat man mal keine Lust, immer nur Spiele zu entwickeln, kann man sich auch im Game Room eine Auszeit nehmen und selbst ein paar Spiele zocken, bis man wieder auf klare Gedanken kommt.
Wooga gehört mit seinem Konzept sichtlich zu den Vorreitern, die sich rasch der wandelnden Arbeitswelt angepasst haben, um auch in Zukunft nur die besten Talente bei sich im Team begrüßen zu dürfen. Mit seiner Feelgood-Strategie schafft das Unternehmen genau die kreative Umgebung, die ihre Mitarbeiter brauchen, um gute Online-Spiele zu erschaffen.

Drei Fragen an Gitta Blatt, Head of People bei Wooga

Gibt es bei Wooga ein spezielles Arbeitszeitenmodell?
Wooga setzt beim Thema Arbeitszeiten auf Vertrauen, da wir davon ausgehen, dass jeder unserer Mitarbeiter persönlich für sich erfolgreich sein möchte. Produktivität ist bei uns wichtiger als reine Anwesenheit. Es gibt in unserem Arbeitsalltag gewisse Ankerpunkte in Form der zwei täglichen Stand-up-Meetings um 9:30 und 18:00, bei denen auch die meisten Teammitglieder anwesend sind. Aber grundsätzlich entscheiden unsere Mitarbeiter selbst, wann sie kommen und gehen.
Wie kommt Wooga auf so kreative Ideen wie den Mystery-Lunch oder die Ruhekojen?
Bei uns wird nichts wirklich geplant. Jeder darf seine Ideen beitragen, das ist wie ein riesengroßes Brainstorming. Ideen, die viele gut finden, werden im Kleinen ausprobiert. Wenn diese funktionieren und auf Anklang stoßen, werden sie etabliert.
Warum sind agile Methoden vor allem in der Softwareentwicklung so populär?
In der Softwareentwicklung herrscht ein hohes Tempo an Innovation und Veränderung. Etwas, das man zu Beginn eines Projekts geplant hat, kann im Laufe der Entwicklung an Aktualität verlieren. Unsere Produkte sind eigentlich nie wirklich fertig, denn die Ergebnisse müssen immer weiter verbessert werden und dafür ist ein hoher Grad an Flexibilität nötig. So ist z. B. ein Spiel von Wooga auch nach der Fertigstellung und dem eigentlichen Launch ein Service, der weiter gepflegt und entwickelt werden muss.

Zwei Jahre Scrum bei EWE

Mit Neugier und Aufregung hat die easy+ Mannschaft von EWE am 8. Oktober 2012, also genau vor 2 Jahren, ihr erstes Scrum Intro Training erlebt. Inzwischen sind bis zu 12 Scrum Teams für die Weiterentwicklung des Abrechnungs- und Kundenmanagement-Systems zuständig. Wir sind stolz, dass wir diese großartige Mannschaft in den letzten zwei Jahren begleiten durften! Alle haben mutige Schritte zur Agilität gemacht, mit den unvermeidlichen Höhen und Tiefen – vor allem aber hat es auch viel Spaß gemacht. In unserer Case Study könnt ihr nachlesen, welchen Weg wir gegangen sind. Inzwischen sind im Konzern andere Initiativen entstanden, die von Lean und agilen Prinzipien inspiriert sind. Um den Austausch zwischen diesen Initiativen zu fördern, haben wir vor Kurzem sogar eine Community of Practice gegründet.
Ich habe ein paar Kollegen bei EWE gefragt, was sie für sich und das Team mitnehmen, wenn sie auf die letzten zwei Jahre zurückblicken:
“Rückblickend finde ich es spannend, dass ich von einem Skeptiker (“Wie soll das denn für eine Organisation unserer Größe funktionieren?”) zu einem Verfechter des agilen Mindsets geworden bin und mir nun gar nicht mehr vorstellen könnte, so zu arbeiten wie früher.” Nils Mathiesen, ScrumMaster of ScrumMaster, EWE swb ISIS GmbH
“Ich habe nicht geglaubt, dass wir in nur zwei Jahren so viel erreichen könnten. Und auf dem Weg ist uns klar geworden, dass wir noch viel mehr auf immer höheren Ebenen bewegen können. Ich bin sehr zuversichtlich, dass wir noch einen langen und lohnenswerten Weg vor uns haben. Vor Kurzem war ein Kollege aus einem anderen Bereich bei uns. Er war gerade ziemlich im Stress bzw. unsicher in einem neuem Projekt, bei dem gerade niemand die Anforderungen kennt. Er wusste einfach nicht, mit welchem Vorgehen er dieses Projekt angehen könnte. Ein Kollege und ich arbeiten jetzt schon seit 2 Jahren mit Scrum und haben oft die Rolle des PO übernommen, daher waren wir von dieser Situation wenig überrascht. Sofort hatten wir eine Vorstellung davon, wie wir damit umgehen würden: ein Discovery Workshop mit Kunden, ein erstes Backlog Grooming, etc.” Markus Theilen, Domain Architekt easy+, EWE swb ISIS GmbH
“Im richtigen Moment gab es immer den richtigen Gloger, um uns zu unterstützen.” Nils Nussbaumer, Domain Product Owner, EWE isis swb GmbH
Danke, dass wir diese Entwicklung begleiten durften und dürfen!
Gemeinsam mit Markus Theilen berichten wir auf der OOP 2015 am 27. Januar 2015 in München über unsere Erfahrungen (Track Di 6.2). Hier geht es zum Abstract.

Jetzt ist es raus: Unser Buch zu Scrum & Personalmanagement

„Erfolgreich mit Scrum – Einflussfaktor Personalmanagement. Finden und Binden von Mitarbeitern in agilen Unternehmen.“ Das ist der Titel des ersten gemeinsamen Buches von André Häusling und mir und – juhu – nach den letzten, sehr schreibintensiven Monaten ist es ab sofort erhältlich!

Scrum wurde schon aus sämtlichen Blickwinkeln durchgekaut. Es waren aber immer wieder die Blickwinkel der Methodik und das ist eigentlich symptomatisch für die Diskussionen rund um Scrum: Alles ist so fixiert auf die Interpretation der „Vorschriften“, dass der eigentliche Kern von Scrum vollkommen ausgeblendet wird. Dieser Kern ist die grundlegende Veränderung, die mittel- bis langfristig nicht nur ein Team allein, sondern eine ganze Organisation betrifft, die sich für den Weg mit Scrum entscheidet.

John Cleese würde sagen: „…and now to something completely different.“ André Häusling und ich waren auch der Meinung, dass es höchst an der Zeit ist, mal über den Softwareentwicklungs-Tellerrand raus zu schauen. Was tut sich denn eigentlich so im Rest eines Unternehmens, wenn Scrum eingeführt wird? Oder was sollte sich tun? Hat das Mindset von Scrum, hat die Tatsache, dass das Team so eine immens wichtige Rolle spielt, haben die neuen Rollenverständnisse nicht eigentlich Einfluss auf Organisationsbereiche wie zum Beispiel das Personalmanagement? Um es mit den Worten von Oliver Zeiler, CTO von ImmobilienScout 24 auszudrücken, der schon vorab einen Blick in unser neues Buch werfen konnte: „Endlich ein Buch, das sich mit den tiefgreifenden Organisationsveränderungen nach der Einführung von Scrum beschäftigt. Speziell die neuen Aufgaben im HR-Bereich sind nicht trivial zu erkennen bzw. zu antizipieren, können aber bei der Einführung von agilen Methoden über Erfolg und Misserfolg entscheiden.“ Aber so wie klassische Instrumente des Personalmanagements derzeit ausgestaltet sind, sind sie nicht immer kompatibel mit agilen Denkweisen.

Die Verantwortung dafür, die Werkzeuge wie Recruiting, Talent Management, Performance Management, Compensation & Benefits, Trennungsmanagement und Führung neu zu formen, kann im Umkehrschluss aber nicht einfach auf HR-Abteilungen abgeschoben werden. Veränderung ist eine Gemeinschaftsanstrengung und daher sehen wir auch ein Scrum-kompatibles Personalmanagement als gemeinsame Verantwortung von Management, ScrumMastern, Product Ownern und Teammitgliedern. In unserem Buch haben wir einige mögliche Wege aufgezeigt, wie ein agiles Personalmanagement aussehen kann, aber auch hier gilt: Es ist kein Lehrbuch, selbständiges Denken und eigene Wege sind erlaubt. Es gäbe noch zig Detailebenen zu betrachten, aber in erster Linie wollen wir zunächst einmal eine Diskussion eröffnen und den Austausch in der Community darüber anregen, wie mit Fragen des Personalmanagements in einem Scrum-Umfeld umgegangen wird und welche Lösungen praktikabel sind.

Natürlich sollt ihr in erster Linie mal das Buch lesen :). Und wenn ihr es gelesen habt, legt es euren Personalern auf den Tisch, damit sie anfangen, mit uns zu diskutieren und zu überlegen und zu verändern. Selbstverständlich werden wir in den nächsten Wochen aber auch in diesem Blog Auszüge aus dem Buch zur Diskussion stellen und wir sind schon gespannt auf eure Meinungen!