Heute ist mein erster produktiver Codeyard-Tag. Codeyard ist unsere neue All-in-one-Atlassian-Lösung, die hoffentlich ebenso erfolgreich wird wie unsere Confluence-basierte Intranet-Plattform Linchpin. Sie bietet den professionellen Atlassian-Stack für Entwicklungsteams (HipChat, Confluence, JIRA, Bitbucket, Bamboo) und alle erforderlichen professionellen Dienstleistungen (organisatorisches und kulturelles Coaching, Beratung, Installation, Konfiguration etc.) zu einem garantierten Festpreis.
Es ist eine teamübergreifende und cross-funktionale Aufgabe, eine solch große Lösung in unserem Unternehmen zum Laufen zu bringen. Kennen Sie diese Situationen? Sie müssen nahezu alle Mitarbeiter (oder zumindest alle Meinungsführer) an einen Tisch bringen, was fast unmöglich ist.
Wir hatten diesmal das Glück, dass einige Kollegen schon damit begonnen hatten, an der Lösung zu arbeiten. Sie kümmerten sich nicht um Themen wie Vision, Strategie, Marketing, Markt-Feedback und so weiter. Sie machten einfach und griffen diese Themen unterwegs auf. Oliver, einer unserer technischen Berater, fing plötzlich an, aufs Geratewohl Kontakte anzurufen und frühere Ansprechpartner aus Consulting-Aktivitäten zu reaktivieren, um sie zu fragen, ob der komplette Atlassian-Stack nicht etwas wäre, worüber es sich nachzudenken lohne. Er machte Vertrieb in seiner puren Form.
Zwei andere Kollegen hackten eine erste Version dieser Deployment-Plattform mit Puppet, einem Konfigurationsmanagement-Tool) – inklusive einer Integration mit einem Cloud-Hosting-Anbieter. So schufen sie die Grundlage einer möglichen künftigen Infrastruktur. Und ein paar weitere Mitarbeiter erstellten eine erste Version einer Visualisierung von Codeyard für Angebote.
All das passierte, ohne dass irgendein Manager irgendein Budget freigegeben hatte. Es passierte, ohne dass ein Ressourcenmanagement irgendwelche Arbeitszeiten für dieses Vorhaben zugewiesen hatte.
Aus meiner Sicht als Geschäftsführer war es des blanke Chaos. Es ist das, was viele Führungskräfte in großen Unternehmen, mit denen ich mich unterhalte, am meisten fürchten. Ich höre sie sagen: "Mitarbeiter verschwenden unser Geld bewusst für halbgare Iterationen von irgendwelchem Mist. Wir brauchen Kontrolle und Koordination für solche Aktionen."
Hier sind ein paar Argumente, die das untermauern.
Die Visualisierung wurde noch einmal von Grund auf neu gemacht. Wir hatten die aktuelle Version bis jetzt nicht veröffentlicht. Verschwendung? Die Deployment-Plattform funktioniert bis jetzt nicht. Wir haben gerade ein paar weitere Entwickler darauf angesetzt. War die Arbeit bis hierin also verschwendet? Wir hatten einige heiße Leads. Die meisten Kontakte haben sich aber noch nicht entschieden. Das ist wahrscheinlich keine Verschwendung, aber hätte die Zeit nicht besser investiert werden können?
Die Antwort auf alle Fragen lautet: Nein! Das Denken des traditionellen Managements ist heute weitgehend überholt. Die große Frage ist nicht mehr, wie wir "effizienter werden können". Heutzutage wird Erfolg in Effektivität gemessen. Hilft Codeyard tatsächlich? Kann es sich von dem abheben, was andere Anbieter für das Application Lifecycle Management entwickeln, die nicht aus dem Atlassian-Umfeld kommen? Können wir es verkaufen? Verstehen es die Kunden? In diesem Moment kenne ich die Antworten nicht.
Aber was das Team gemacht hat, ist genau das, was wir brauchen, um diese Fragen zu beantworten. Sie haben ein Lean Canvas für Codeyard erstellt und die Hypothesen getestet, die am kritischsten für den Erfolg des Geschäftsmodells sind. Sie haben getestet, was für das Modell am riskantesten ist. Und sie haben die Entscheidungen ohne Managementfreigabe getroffen. Sie haben Zeit und Geld verbraucht. Wir haben sogar Domain-Namen für mehrere tausend Dollar gekauft.
Ich muss aber gestehen, dass ich ein wenig involviert war. Ich kenne die Idee hinter Codeyard und unterstütze sie. Ich habe sogar dieses Video aufgenommen:
Sie sehen gerade einen Platzhalterinhalt von Youtube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Ich vertraute darin, dass die eingebunden Personen Ergebnisse liefern und die inhärente Verschwendung begrenzen würden, die mit iterativen Modellen einhergeht. Aber erst heute habe ich "offiziell" angefangen, mit am Projekt zu arbeiten.
Ich finde das Modell dieser Arbeit an sich erwähnenswert. Einer unserer Mitarbeiter schickte intern einen Post mit einem Doodle-Link herum, in dem es sinngemäß hieß: "Wir haben individuell ein paar Sachen umgesetzt. Aber wollen wir uns nicht regelmäßig zusammensetzen und Seite an Seite arbeiten, um das gemeinsame Gefühl zu bekommen, ein Team zu sein? Das hilft uns beim Synchronisieren und Koordinieren. Auf diese Weise reservieren wir eindeutige Zeitblöcke, um Codeyard konsistent voranzubringen. Und wir müssen niemanden aus seinem angestammten Team rausreißen." Die Doodle-Koordination hat gut funktioniert. Und so arbeite ich von jetzt an jeden Freitag von 10 bis 14 Uhr gemeinsam mit einem Team von Freiwilligen an Codeyard.
Und es gibt einen großen Unterschied zu den üblichen Wochen-Meetings, die ich in großen Unternehmen oft sehe. Unser Zeitfenster ist fürs Arbeiten vorgesehen, nicht fürs Reden. Sicher reden wir jede Menge. Aber nicht mit allen im Raum. Leute kommen zu einer Diskussion und gehen wieder raus, wie es ihnen passt.
Ich liebe diesen neuen nicht-deterministischen Stil der Organisation, den ich vor allem dank Niels Pfläging, Lars Vollmer und Gerhard Wohland kennengelernt habe. Er funktioniert für mich (und für unser Unternehmen) großartig.
Aber ich kämpfe noch mit einer Sache. Ich tendiere nach wie vor dazu zu denken, dass ich fünf Dinge in vier Stunden tun könnte, und tatsächlich habe ich nur diesen Blog-Artikel gemacht. Dazu habe ich 45 Minuten gebraucht. Das deckt sich also soweit mit meinen Erwartungen. Dann passierte etwas anderes. Ich wollte zusätzlich Demoinhalte für die Atlassian-Tools in Codeyard erstellen. Das ist theoretisch kein großes Problem. Aber die Frage kam auf: "Was ist das übergeordnete Thema für diese Demoinhalte?"
Für neue Programmiersprachen scheint ein gebräuchliches Thema zu sein: "Baue deinen eigenen Online-Zooladen." Also wurde das zuerst auch unser Thema. Dann haben wir es schließlich variiert: "Wir bauen unser eigenes Intranet."
Die Diskussion zuvor dauerte zwei Stunden. Vor- und Nachteile kamen zur Sprache. Der offensichtliche Nachteil ist, dass ein Intranet zu bauen deutlich komplexer ist als einen Online-Zooladen. Die Vorteile dagegen sich zahllos: Jedes Unternehmen braucht ein gutes Intranet. In meinem "normalen" Leben dreht sich heute alles um tolle Intranets. Für mich ist es viel einfacher, als Nebenprodukt Demoinhalte für Codeyard zu generieren.
Um einen kompletten Codeyard-Anwendungsfall daraus zu machen, kann das Intranet nicht "out of the box" kommen wie Linchpin, sondern muss als Software via Continuous Deployment entwickelt werden. Unser agiles Demoprojekt wird Initiativen, Themen, Epics, Vorgänge und Aufgaben haben. Diese werden sich um News, Meetings (Raumplanung, Ressourcenmanagement), Mitarbeiter, Microblogs, Kantinenpläne und Firmen-Events drehen.
Wenn wir eines Tages in der Lage sein sollten, einen kompletten Atlassian-Stack via Codeyard zu deployen, können Sie mich wegen meines mangelnden Einfallsreichtums tadeln. 😀
Ich will diesen Artikel mit der "unfertigen" und "unveröffentlichten" Visualisierung abschließen, die zu diesem Zeitpunkt nochmal neu gemacht wird:
Weitere Infos
Codeyard: Voraussetzungen für einen erfolgreichen Software-Entwicklungsprozess schaffen
Unsere spezielle Infothek-Seite über Codeyard mit ausführlichen Infos, Features und Preisen
Mehr über die Creative-Commons-Lizenz erfahren
