Es ist interessant darüber nachzudenken, wie wir herausfinden welche Probleme unsere neue Lehrer-App genau lösen soll. Als Lehrer weiß ich genau, was ich brauche, was ich während des Unterrichts festhalten möchte. Zu Beginn eines Schuljahres brauche ich Hilfe dabei, all die Namen meiner Schülerinnen und Schüler zu lernen. Warum? Wenn ich jemanden bitte mir eine Frage zu beantworten, und sie oder ihn dabei persönlich anspreche, richtet der Schüler sich auf und nimmt Notiz von mir. Ich will ehrlich sein. Natürlich frage ich Schüler die unaufmerksam sind, um ihnen zu zeigen, dass ich sie wahrnehme und sie auch mich wahrnehmen sollen. Das funktioniert aber nur, wenn ich sie direkt ansprechen kann. Natürlich möchte ich auch festhalten, welche Schüler fehlen – und wenn sie wieder da sind möchte ich durch die App erinnert werden die Schüler zu fragen, warum sie nicht da waren. Meistens freuen sich Schüler, wenn man bemerkt dass sie gefehlt haben. Niemand wünscht sich, dass keiner es bemerkt. Wenn Schüler krank waren, möchte ich sie zurück begrüßen und ihnen sagen, dass ich mich freue dass es ihnen wieder besser geht. Eine solche Lehrer-App würde mir wirklich dabei helfen, die Beziehungen zu meinen Schülern zu verbessern. Wenn diese Beziehungen gut funktionieren und die Schüler verstehen dass ich mich um sie kümmere, geht auch alles Andere leichter. Es gibt noch viele weitere Probleme, bei denen die neue Lehrer-App mir helfen kann. Definitiv muss ich Hausaufgaben die auf Papier – also offline – eingereicht werden, festhalten können. Manche Schüler reichen Hausaufgaben lieber elektronisch, andere lieber auf Papier ein. Ich brauche ein Übersicht der fehlenden Aufgaben. Und der offline eingereichten Aufgaben, damit ich diese wieder zurückgeben kann. Die Lehrer-App ermöglicht mir genau das schon jetzt, so dass ich dann Zuhause oder im Lehrerzimmer die Aufgaben benoten und letztlich alle Hausaufgaben gleich behandeln kann – egal ob sie elektronisch oder auf Papier abgegeben wurden. Genau diese vermeintlichen Kleinigkeiten sind mir wichtig. Echte Anwendungsfälle, basierend auf echtem Unterricht machen meinen Schulalltag einfacher und helfen mir ein gutes Verhältnis zu den Schülern zu schaffen. Im besten Falle ist diese kleine Lehrer-App nahtlos in mein Learning Management System integriert. Genau das finde ich das Spannende an meinem Job. Meine Aufgabe ist es genau Das zu entwickeln, was meinen Anforderungen und denen anderer Lehrer entspricht. Warum ich das mache? Weil ich ehrlich gesagt nicht das beste Gedächtnis habe. Ich vergesse Dinge. Aber auf diese Art und Weise kann ich mich an die kleinen Dinge erinnern, die für die Schüler den Unterschied ausmachen. Ok, wenn ich dazu Technologie brauche… Aber genau dafür ist diese ja da. Peter arbeitet als Lehrer und ist bei uns u.a. für User-Stories verantwortlich.

User Stories sind der heilige Gral in der agilen Softwareentwicklung. Es gibt eine Art sie gut zu schreiben und hundert schlechte. Obwohl sie recht simpel sind, verstehen viele Produktentwickler sie falsch. Wir benutzen die Standardform: ‚Als Lehrer will ich einen Kurs erstellen, sodass ich Materialien mit meine Schülern austauschen kann.’ Jede User Story hat Prerequisites oder Voraussetzungen: ‚der Kurs existiert nicht’. Und wir haben Postrequisites oder Zielergebnisse: ‚der Kurs existiert’. Danach schreiben wir die User Story in Pseudocode. Dieser ist genauso aufgebaut, wie Programmier-Code. Der einzige Unterschied ist, dass man sich nicht an bestimmte Programmierkonventionen halten und deswegen nicht darauf achten muss ob der Code am Ende compiled werden kann. Eine gute User Story kann in Scrum-Planung eingeschätzt werden und darf nicht über 8 Story-Punkte lang sein. Wenn sie das Limit überschreitet, dann muss sie in zwei oder mehr Stories runtergebrochen werden. Die größte Story war bisher 5 Punkte groß, das heißt wir haben einen guten Job gemacht. Pro Zweiwochen Sprint schaffen wir rund 25 Punkte. So hat es bis jetzt immer gut geklappt, die Entwickler haben alle Sprints erfolgreich abgeschlossen. Darüber hinaus nehmen sie immer noch ‚technische’ Stories mit in den Sprint auf. Beim sogenannten Refactoring werden Teile des Codes neu geschrieben wenn dadurch die Performance der Seiten verbessert wird. Auch die Infrastruktur muss weiterentwickelt werden. Bei der Sprintplanung werden alle User-Stories auf Karteikarten geschrieben. Diese nehmen die Entwickler mit in ihr Büro und haften sie an unser Kaban-Brett, aufgeteilt in die Felder ‚offen’, ‚in Arbeit’, ‚erledigt’. Es ist schön zu sehen, wenn am Ende des Sprints alle Karten im letzten Feld hängen.

Eine Person ist in der Softwareentwicklung eine Art Melange aus realen Personen. In unserem Fall ist es ‚William’ der einen normalen hart arbeitenden Lehrer repräsentiert, der Hausaufgaben stellt. Einige Schüler reichen sie online ein und einige auf Papier. Andere reichen gar nichts ein. Einige sagen sie werden was einreichen und machen es dann nicht, einige sagen sie werden es nicht machen und reichen dann doch was ein. Manche Schüler waren krank als die Aufgabe gestellt wurde und manche Schüler sind krank wenn die Aufgabe eingereicht werden soll. Wieder andere Schüler fragen nach einer Verlängerung der Frist. Die Liste der Einzelfälle ist endlos. Und all das passiert bevor der arme William auch nur eine Hausaufgabe benotet hat. Aber dies ist die Welt in der Scolibri funktionieren muss. Deswegen müssen wir diese Welt verstehen. Wofür brauchen wir die Personen? Wir nutzen sie um eine Geschichte über ihr Arbeitsleben zu erzählen. Diese Geschichte nennen wir sein Szenario. Dieses Szenario nutzen wir um zu prüfen ob wir alle User Stories vorbereitet haben, sodass das fertige Produkt William bei seinem Job unterstützt. Das ist alles? Nein. Zusätzlich testen wir mit dem Szenario die Funktionalität unserer Wettbewerber. Wir können keine Aussage über unsere Konkurrenz treffen, wenn wir keine standardisierte und realistische Testmethodik haben. Das funktioniert super und wir haben einiges gelernt. Dafür sind also Personen und Szenarien da? Nicht ganz. Sie spielen auch in die Produktdemos mit rein. Wir fragen Laurin nicht ob er uns diese oder jene User Story vorführen kann. Basierend auf dem Szenario entwickeln wir Softwaretests und simulieren einen Lehrer, der genervt ist und die Software mit realistischen Daten testet. Dadurch wird die Demo für uns viel plastischer. Diese Daten sind auch Teil des letzten Tests, bevor wir die Betaversion veröffentlichen. Unser Ziel ist es alle Tester zufriedenzustellen. Wir wollen alle möglichen Blickwinkel aufs Produkt mit einbeziehen. Und es muss schnell gehen. Mit der Szenario-Methode sind wir unglaublich schnell. Möglich, dass Williams Story nicht real ist aber sie ist sehr nah an einer wirklichen Geschichte. Denn William ist im realen Leben ein Lehrerkollege von Peter an der Nelson Mandela Schule. Er weiß aber nichts davon. Vielleicht wird er berühmt.

Was wollen diese Investoren sehen? Was wollen sie wissen? Die Software ist noch nicht fertig, also warum entscheiden sie sich dazu in uns zu investieren? Sie kaufen UNS. Sie ‚kaufen’ uns nicht wirklich, wir sind unverkäuflich. Aber sie wollen an uns glauben, Sie müssen an uns glauben. Und sie werden uns nicht glauben, wenn wir nicht an uns glauben und wenn sie nicht daran glauben, dass wir es schaffen können. Können wir es schaffen? Softwareentwicklung ist schwer. Gute Software zu entwickeln ist sehr schwer. Dafür braucht man gute Voraussetzungen und vor allem ein gutes Team. Kein gewöhnliches Team, nicht Menschen, die einfach nur zusammen arbeiten. Ein gutes Team bildet komplementäre Eigenschaften ab und teilt dieselbe Vision. Wie können wir sicher sein, dass alle die gleiche Vision teilen? Wie können wir wissen, dass die Vision auch Lehrer überzeugt und sie sich sagen: „Hey, genau darauf habe ich gewartet.“ Scolibri wird nicht funktionieren, wenn wir versuchen das Verhalten der Lehrer zu ändern. Stattdessen müssen wir den Lehrer komplett verstehen. Wir sind alle Kunden des Bildungsbereichs, wir waren alle auf einer Schule. Sind wir deshalb Lehrer-Experten? Nein. Wir sind Experten des „Schulerlebnisses“. Ich erinnere mich aber stärker an all das was außerhalb des Klassenraums stattfand. Deswegen brauchen wir einen Lehrer. Einen Lehrer, der Softwareentwicklung versteht. Total einfach? Naja, wir haben auf jeden Fall einen gefunden. Wir haben die Passion. Wir haben die technischen Fähigkeiten. Wir brauchen eine gemeinsame Vision. Eine geteilte Vision. Weil wir an uns glauben und weil wir wissen dass wir es schaffen können, wird es uns auch gelingen dieses Gefühl an Investoren zu vermitteln. Und Investoren kennen den Unterschied weil sie all das schon oft gehört haben. Es geht nicht ums verkaufen weil verkaufen ist nicht gut genug. Wir müssen es leben und dadurch authentisch rüberbringen wie sehr wir an die Vision glauben. Das kann man nicht faken. Investoren haben einen ausgeprägten Bullshit-Radar. Wenn wir schlecht riechen würden, würden sie es merken, wir würden kein Geld bekommen und wären nicht mehr hier. Aber wir sind hier und wir haben das erste Geld eingesammelt. Aber wir brauchen mehr. Natürlich ist Berlin nicht das Silicon Valley, sondern die Silicon Allee. Deswegen steht und fällt Scolibri mit unserem Produkt. Soweit so gut. Wir müssen unsere User verstehen, wir brauchen Entwickler-Genies und wir brauchen eine Ladung Leidenschaft. Wenn ich nachts aufwache und merke, dass ich von Scolibri geträumt habe, dann bin ich mir sicher, dass wir die schweren Sachen richtig machen.

Iterative Softwareentwicklung ist anspruchsvoll. Weil es schwer ist, sich auf das Minimum Viable Product (MVP) zu konzentrieren und weil es schwer ist, tatsächlich eine Beta-Version fertigzustellen und an die Nutzer zu bringen. Aber nur so können wir testen, ob wir an dem nächsten großen Hit arbeiten. Und bald ist es soweit… Erinnere dich an die Geschichte mit den drei kleinen Schweinchen. Das erste Schweinchen hat sein Haus aus Stroh gebaut, das zweite Schweinchen eines aus Holz und das dritte Schweinchen eines aus Ziegelsteinen. Das Strohhaus haben wir schon gebaut, jetzt brauchen wir ein Holzhaus. Nur was für ein Holzhaus soll es sein? Ein Baumhaus? Ein Schuppen? Ein Bauernhaus im Ranch-Stil mit Pool? Was fehlt noch? Auf jeden Fall brauchen wir eine Säge, Hammer, Nägel, Holz und Hilfe. Wer wird uns helfen, das Haus zu bauen? Die Helfer müssen genau wissen, welche Rolle sie in der Geschichte spielen und sie müssen etwas beitragen. Wenn die Zuhörer dem Geschehen nach dieser Episode weiter folgen, dann entsteht hier eine Erfolgsgeschichte. In den nächsten Wochen werden wir einige Blogposts schreiben um tiefer in die einzelnen Themengebiete einsteigen.