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.

Ich habe n’ Namensgedächtnis wie ein Sieb, aber ich erinnere mich an Herrn Mehlmann.

Ehrlich gesagt, weiß ich nicht wie es bei Dir war… Ich kann mich an die wenigsten meiner Lehrer erinnern. Vielleicht erinnerst Du Dich doch, ich jedenfalls nicht. Na gut, an ein paar dann doch. Ich erinnere mich besonders an meinen Wirtschaftslehrer Horst Mehlmann vom Antonius Gymnasium. Er war cool. Er hatte einen Bart, einen Beagle und er lief Marathon. Er war definitiv anders als die meisten Lehrer.

Als er sagte “Stellt Fragen.”, meinte er es auch so. Eines Tages stellte ich eine Frage, die nicht mal er beantworten konnte. Am nächsten Tag kam er zu mir und sagte: “Ich habe die Antwort auf deine Frage herausgefunden…”. Es ging um den Unterschied zwischen Dividenden und Derivaten… Die Frage ist eigentlich aber auch egal. Es kam darauf an, dass er mich nicht vergessen hatte und die Antwort herausfand. Das war mir zum ersten Mal passiert! Das hat mich sogar ein wenig stolz gemacht. Ein Lehrer hört mir zu und kümmert sich um mich, um meine Fragen.

Wenn Du diesen Beitrag liest, dann weißt Du etwas über uns und was wir bei Scolibri machen. Um uns war es zuletzt ein bisschen still – weil wir gearbeitet haben. Fokussiert gearbeitet haben. Aber jetzt haben wir etwas, was wir allen zeigen wollen – unser Produkt. Es ist unsere Plattform und wir haben uns einen tollen Contest ausgedacht. Wir möchten die Geschichte von Eurem besten Lehrer hören. Schreibt uns eine kleine Geschichte, um den Contest zu gewinnen. Und so funktioniert’s:

Klicke auf folgenden Link: https://secure.scolibri.com Registriere Dich als Schüler. Wähle den blauen Button oben links in der Plattform aus. Gib folgenden Code ein um der “Investors Class 2013 A” beizutreten: lwxv12 Sobald Du im Kurs bist, siehst Du wie der Contest funktioniert. Geh auf Hausaufgaben um Deine Geschichte zu schreiben. Das war’s! Wenn Du weitere Leute einlädst, hast Du die Chance einen Anteil von Scolibri zu gewinnen.

War’s das wirklich? Wenn Du willst schau Dir die Plattform an. Wir haben sie benutzt, um sie Dir zu zeigen. Du kannst damit natürlich auch arbeiten. Und wie geht’s weiter… Später im Jahr gibt es einen weiteren Contest. Wir werden Deutschlands besten Lehrer finden! Das wird witzig. Also, los geht’s. Erzähle uns Deine Geschichte!

Bildquelle: Starmanseries

Wenn der Kopf müde wird gibt es zwei Möglichkeiten. Entweder man fährt in den Urlaub – oder man atmet Frischluft, draußen, außerhalb der Stadt. Also einsteigen in Auto oder S-Bahn und los geht’s. Angekommen in den suburbanen Gegenden Berlins wird auf einem schönen Waldparkplatz gerastet. Unterwegs hatte man ausreichend Zeit um Schilder oder Haltestellen auswendig zu lernen. Das kann sogar Spaß machen, wer auf der Rückfahrt die meisten “Richtigen” hat, dem winkt ein Kaltgetränk. Oder zwei. Wenn man ausreichend Kleingeld zur Verfügung hat, gibt man dem Team noch ein Stück spanische Erdbeertorte aus, natürlich mit viel Schlagsahne… Vielleicht funktionieren diese Teambuilding-Maßnahmen. Es geht aber auch anders, vielleicht ein wenig besser, ehrlicher. Das schöne an Geschichten ist, dass man anfangen kann sie von vorne zu erzählen. Wenn der Kopf müde wird gibt es zwei Möglichkeiten. Urlaub oder Kurzurlaub. Also rauf auf’s Rad. Raus aus der Stadt. Angekommen in den suburbanen Gegenden Berlins Halt an der Spree, dem Oder-Spree-Kanal, dem Seddin- oder Müggelsee. Wenn auch ohne Haialarm. Dem war es wohl zu kalt. Frei nach dem Motto der Weg ist das Ziel. Das mag vielleicht etwas abgedroschen klingen, funktioniert aber großartig. Das so eine Auszeit für uns alle mal an der Zeit war zeigt sich schon daran, dass zum (samstags!) morgendlichen Pfannkuchenessen niemand zu spät kommt. Auch wenn dem ein oder anderen Fahrrad die Luft weggeblieben war. Gestärkt und aufgepumpt fahren wir also los. Gänsemarsch in der Stadt, später dann der “Belgische Kreisel” auf freier Strecke mit anschließender Sprintwertung. Natürlich haben wir den ganzen Tag Sonnenschein und Rückenwind. Der Tag war ein voller Erfolg für Scolibri. Wenig Input, maximaler Output. Einer lacht, Alle lachen. Auch Peter. Wir haben unseren Coach eingeladen seine Sportlichkeit unter Beweis zu stellen. Meistens sieht Peter sich als “Bruder” von uns, als er am Ende des Tages doch in die S-Bahn steigt wohl eher als “Vater”: “Because I am old. Exhausting, but it was great fun.” “Yes, it was awesome”.

Der Rest fährt der Sonne hinterher bis wir Friedrichshagen erreichen. Da gibt es im Kaiser’s keine Erdnüsse, kein kaltes Bier, dafür aber total nette Menschen. Lukas wird von einem Passanten gebeten eine Zigarette zu drehen. Der geht auf Krücken, ist zwei Meter groß und nach zehn Minuten wissen wir er ist auf Freigang. Gekonnt (und ein wenig ehrfürchtig) dreht Lukas die gewünschte Zigarette und bekommt das netteste “Dankeschön”. Während zwei Meter Freigänger Lukas in den Arm nimmt hören wir noch ein “Du bist ja eine richtige Hackfresse”… Ein Tag voller Geschichten, Erlebnisse neigt sich dem Ende zu. Auch wir fahren mit der S-Bahn nach Hause. Aber nur, weil niemand ausreichende Beleuchtung am Rad hat. Die Moral. Gutes Stichwort. Als kleines Team reicht es auch mal völlig aus “zu machen”, Dinge Dinge sein zu lassen. Besser als jedes Teamseminar. Genau jetzt erinnere ich mich daran die nächste Route aus dem Hut zu zaubern. Nächste Woche ist ja wieder Rückenwind.

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.

Schließlich müssen wir aber von der schönen realen Welt Williams und seinen Szenarien Abschied nehmen, und uns der kalten Welt der Informatik zuwenden. Wir müssen Laurin und seinen Entwicklern etwas geben, woraus sie Software bauen können. Ein Epos ist eine sehr große Geschichte, zu groß um in einem Sprint umgesetzt zu werden. Nur deswegen brauchen wir Epen. Stell dir eine Reihe von zusammenhängenden User Stories vor. Was ist eine User Story? Das werde ich in einem späteren Post erklären. Ok, ich fange doch jetzt schon an. Eine User Story ist die logische Beschreibung einer Funktion. Und jede User Story muss dem Nutzer einen realen Mehrwert liefern. Einfach. Ein Epos ist dementsprechend eine Aneinanderreihung von kleinen wertvollen Funktionen, die am Ende einen großen Mehrwert für den Nutzer bieten. Aber warum gerade User Stories, eine Grafik würde doch sicher auch funktionieren. Schon, aber für die logisch denkenden Entwickler ist die abstrakte Beschreibung anhand der Stories am einfachsten zu verstehen. Außerdem ist die Reihenfolge der User Stories wichtig, um die Sequenz der Tests festzulegen. Cool. End-to-end Tests mit Epen. Melde dich hier an! Und Rollen? Also William ist keine Rolle, sondern ein Lehrer (namens William). Eine Rolle ist abstrakter. Zum Beispiel haben wir die Rolle des ‚Lehrers’. William ist ein Lehrer, genau wie seine Kollegen in Berlin, Deutschland, Europa und überall sonst auf der Welt. Eine Rolle ist eine Sammlung von Verhaltensweisen die nur bei einer Gruppe von Nutzern auftreten. Eine weitere Rolle ist der ‚Schüler’. Lehrer stellen Hausaufgaben, Schüler beantworten Hausaufgaben. Das ist alles. Einfach.

Vor einem Jahr haben wir zum ersten Mal systematisch unseren Markt und unsere Wettbewerber analysiert. Ziel war damals einen groben Gesamtüberblick für den gesamten Bildungsmarkt auszuarbeiten. Dabei kam heraus, dass im Bereich Schulen eine Reihe etablierter Anbieter agieren. Große Namen sind Itslearning, Fronter und Moodle. Sie verfolgen ein top-down Modell bei dem sie ihre Lösungen explizit an Schulen vertreiben. Deswegen sind sie nur indirekte Konkurrenten.

Darüber hinaus gibt es eine Reihe weiterer Unternehmen, die ein scolibri-ähnliches Produkt anbieten und die wie wir mit einem bottom-up Ansatz individuelle Lehrer der Sekundarstufe ansprechen. Die vielversprechendsten Wettbewerber habe ich nun genauer unter die Lupe genommen. Um nicht betriebsblind an die Analyse heranzugehen wurde ich von Peter Merrick unterstützt. Er lehrt an der Berliner Nelson-Mandela-Schule und hat die Wettbewerber aus der Perspektive des Lehrers unter die Lupe genommen.

Systematik

Im ersten Schritt haben wir die Analysekriterien festgelegt. Dafür haben wir eine Liste mit verschiedenen Funktionen aus dem realen Schulleben aufgestellt, die Peter von einer Softwarelösung mindestens erwartet. Dabei haben wir bewusst nicht an einem Poweruser orientiert, sondern an einem durchschnittlichen Lehrer. Der minimale Funktionsumfang beinhaltet:

– Einen Lehrer-Account erstellen.

– Einen Kurs erstellen.

– 100% der Schüler zu dem Kurs hinzufügen.

– Hausaufgaben stellen.

– Hausaufgaben bewerten.

– Usw.

Im zweiten Schritt haben wir die Bewerber ausgewählt. Edmodo.com und Schoology.com sind von den Nutzerzahlen her die größten Anbieter in diesem Bereich. Dazu haben wir das Startup Lore.com einer näheren Betrachtung unterzogen, da es ein sehr ansprechendes User-Interface bietet.

Im dritten Schritt haben wir geprüft ob die einzelnen Funktionen unserer Liste bei den Konkurrenzprodukten angeboten werden, ob sie von unserem Lehrer Peter gefunden und auch benutzt werden können.

Im vierten Schritt haben wir die Ergebnisse zusammengefasst und bewertet. Ziel war es die Schwächen der Wettbewerber aufzuspüren und mögliche Stärken in unsere Produktentwicklung mit einfließen zu lassen. Im Anschluss haben wir unsere Analyse vor dem gesamten Team präsentiert um sie für den letzten Feature-Sprint vor dem Minimum Viable Product (MVP) zu motivieren. Denn die Ergebnisse waren äußerst erfreulich.

Edmodo

Edmodo ist ein US-Amerikanisches Unternehmen das nach eigenen Angaben rund 15 Millionen Nutzer in 120.000 Schulen aufweist. Zuerst fällt die starke Ähnlichkeit mit Facebook auf. Die Farben, das Layout, die Icons – kurz, die Gemeinsamkeiten sind groß. Da viele Lehrer skeptisch sind wenn es um Facebook geht, ist die große Ähnlichkeit nicht unbedingt förderlich für die Verbreitung. Ein noch größeres Problem bei der Nutzung Edmodos war die missverständliche Benennung der Funktionalitäten. Kurse werden dort Gruppen genannt, was Peter anfangs verwirrte und letztlich frustrierte. Er erwartet eine eindeutige und auf Lehrer abgestimmte Benennung, sonst fühlt er sich überfordert und dumm. An dem Punkt würde er die Software schon nicht mehr weiter nutzen. Weitere negative Punkte waren die generelle Unübersichtlichkeit (wichtige Funktionen sind nur schwer zu finden) und der unlogische Definitionsspielraum bei der Benotung (es ist möglich 900 von 100 möglichen Punkten zu vergeben) die Peter ebenfalls verunsicherten. Letztlich gab er Edmodo ein schlechtes Zeugnis und würde die Software auf keinen Fall benutzen.

Schoology

Schoology kommt ebenfalls aus den Vereinigten Staaten und wird von rund 1 Millionen User an 18.000 Schulen genutzt. Von der Funktionalität her ähnelt die Anwendung stark Edmodo. Die Benennung der Funktionen ist hier zwar gelungen, allerdings schwächelt auch Schoology im Bereich Übersichtlichkeit und die Benotung funktioniert nicht einwandfrei. Aufgrund der Mängel würde Peter auch diese Anwendung nicht nutzen.

Lore

Über den letzten Wettbewerber Lore wird laut eigener Aussage an 600 Institutionen eingesetzt. Als erstes fällt die Schlichtheit und das aufgeräumte Interface auf, was nach den beiden vorherigen Anwendungen eine Wohltat für die Augen war. Dementsprechend freudig fing Peter an, mit dem Produkt zu spielen. Beinahe alle Funktionen sind an dem erwarteten Patz zu finden und lassen sich intuitiv bedienen. Aber dann fangen die Probleme an. Die Funktionen sind teilweise fehlerhaft, verhalten sich unerwartet oder sind schlicht falsch konzipiert. Darüber hinaus besteht nicht die Möglichkeit Noten zu vergeben. Wir hatten das Gefühl, dass wir mit der Fassade einer Software arbeiten. Von außen schön anzusehen, aber dahinter verbirgt sich nichts. Letztlich ist Lore ein schönes Werkzeug, das aber nicht viel kann. Deswegen würde Peter auch dieses Produkt nicht verwenden.

Fazit

Abschließend lässt sich sagen, dass Edmodo und Schoology zwar funktionieren, allerdings sind sie frustrierend unübersichtlich und die Funktionen sind nicht auf den Lehrer zugeschnitten. Lore bietet ein aufgeräumtes und eingängiges Interface-Design. Allerdings sind wichtige Funktionen nicht durchdacht oder fehlen komplett. Unser Lehrer Peter würde keines der Produkte nutzen, da sie ihm nicht die nötige Sicherheit geben, die er braucht um sich für ein System zu entscheiden. Am Anfang muss ein Lehrer Zeit investieren um seine Daten einzupflegen. Das wird nur geschehen, wenn er sich absolut sicher fühlt und die Software ihn nicht verwirrt oder das Gefühl gibt, dass er dumm ist.

Das Fazit aus der Analyse lautet deshalb wie folgt:

Alles ist möglich – Es gibt kein Produkt am Markt das sich komplett an den Bedürfnissen der Lehrer ausrichtet. Deshalb bietet der Markt noch enormes Potenzial.

Größer als Deutschland – Die weltweit größten Wettbewerber haben noch keine passenden Lösungen für Lehrer entwickelt. Deswegen entwickeln wir ein internationales Produkt.

Verkaufe den Nutzer nicht für dumm – Der Nutzer muss im Mittelpunkt unserer Bemühungen um ein gutes Interface Design stehen. Anstatt überfordert und dumm soll er sich verstanden und sicher fühlen. Nur so wird er den Schritt von Stift und Zettel zu einem Online-Tool wagen.

Entwickle etwas Wertvolles – Nur wenn wir dem Lehrer einen Mehrwert bieten, haben wir eine Daseinsberechtigung. Deswegen müssen wir alle unsere Aktivitäten darauf ausrichten, den Nutzern ein hervorragendes Produkt zu liefern.

Um diese Ziele zu erreichen werden wir Peter in Zukunft stark in die Produktentwicklung mit einbeziehen und auch in der kommenden Betaphase das Feedback der Lehrer aufnehmen und umsetzen. So werden wir erfolgreich die Zukunft der Schule mitgestalten.

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.

Zu Anfang eine Jobbeschreibung. Gesucht: Person mit Lehrerfahrung und tiefgreifendem Verständnis im Bereich agile Softwareentwicklung und Scrum. Sie muss User Stories identifizieren, schreiben und priorisieren. Weitere Voraussetzungen sind das Schreiben der User Story Tests, Managen von Produktdemos und die Unterstützung des Technikteams. Also brauchen wir einen Softwarespezialisten der User Stories schreiben kann und gleichzeitig Lehrer ist. Einfach oder? Ach ja, wir können auch nicht viel zahlen, wodurch das Unterfangen überhaupt eine Bewerbung zu bekommen noch unwahrscheinlicher wird. Aber wie es der Zufall so will haben wir genau diese Person im Betahaus getroffen – Peter. Ok, der Job ist eigentlich zu groß für eine Person. Deswegen arbeiten Peter und Oliver zusammen und formen zusammen die Zukunft des Produkts. Und wie läufts? Es funktioniert sehr gut. Der Einfluss auf Team, Moral und der Fortschritt sind enorm. Es fielen einfach alle Teile zusammen. Die Entwickler fingen an in Vollzeit zu arbeiten, wir bekamen ein neues Büro (eher eine Bude, aber mittlerweile gefällt es uns) und wir haben erstklassige User Stories die darauf warten umgesetzt zu werden. Sie sind so gut, dass unsere Entwickler einfach loslegen können und genau wissen was zu tun ist. Sie sind glücklich. Und glückliche Entwickler sorgen für ein glückendes Projekt. Es fängt bei der Vorplanung mit einem Stapel von User Stories an. Sind es genug? Ja. Sind sie gut geschrieben? Sehr gut. Sie wurden alle in Pseudo-Code geschrieben und logisch bis ins letzte Detail durchdacht. Kein Wunder, Peter hat einen Doktor in Informatik. Und er ist witzig. Er ist alt, aber witzig. Das ist wichtig nach acht Stunden logischem Denken. Wir können uns keine langen Gesichter erlauben.

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.