<header class="standard-header" style="background-image: url(../../assets/bg-images/general/visual-trainings-01.jpg); background-color: var(--overlay-standard-color);">
    <h1 class="standard-header__title">Hey ho, let's go</h1>
    <h2 class="standard-header__subtitle">...</h2>
    <div class="standard-header__intro">
        <span class="standard-header__intro__label">fintech</span>
        <div class="standard-header__intro__text">
            Zu oft werden in Softwareprojekten zu viele neue Dinge gleichzeitig
            ausprobiert, ohne dass der Business Value erkennbar wäre- und vor allem,
            ohne die Risiken vorher abzuschätzen. Eine Möglichkeit, die unnötige
            Technologieüberflutung zu vermeiden, sind Innovation Tokens. Mit diesen
            lassen sich Innovationen in geregeltere Bahnen lenken und bieten eine
            Grundlage für weniger emotionale Technologiediskussionen.
        </div>
        <div class="content-separator content-seperator--inverted">
            <time class="content-separator__date date" datetime="2017-06-26">26. Juni 2017</time>
            <hr class="content-separator__separator" />
            <time class="content-separator__duration duration" datetime="P8M">8 Min. Lesedauer</time>
        </div>
    </div>
</header>
<main role="main">
    <article class="page-layout--grid">
        <aside class="left toc">
            <h3 class="toc__heading">Inhalt</h3>
            <ol class="toc__list">
                <li><a class="toc__anchor" href="#dilemma">Das Dilemma: Innovation vs. Chaos</a></li>
                <li><a class="toc__anchor" href="#idee">Die Idee hinter Innovation Tokens</a></li>
                <li><a class="toc__anchor" href="#unbekannt">An die unbekannten Unbekannten denken und besonders darauf
                        achten</a></li>
                <li><a class="toc__anchor" href="#ballast">Kognitiven Ballast vermeiden</a></li>
                <li><a class="toc__anchor" href="#fokus">Fokus auf die Wertschöpfung legen</a></li>
                <li><a class="toc__anchor" href="#fazit">Fazit</a></li>
            </ol>
        </aside>

        <section class="center">
            <h3 id="dilemma">Das Dilemma: Innovation vs. Chaos</h3>

            <p>Eine neue Technologie ins Unternehmen oder Projekt einzubringen, verursacht Kosten. Aber sind wir uns
                wirklich im Klaren darüber, über welche Kosten wir hier sprechen? Wenn wir ein Team von erfahrenen
                Java-Entwicklern haben, wird der Vorschlag, neue Anforderungen an unsere Anwendung mit Python
                umzusetzen, vermutlich Stirnrunzeln hervorrufen. Denn uns wird relativ schnell bewusst, dass die
                Anwendung dadurch komplexer werden würde. Wir würden uns fragen, ob das Team dies handhaben kann und ob
                unser Betrieb dem gewachsen ist.</p>

            <h3 id="idee">Die Idee hinter Innovation Tokens</h3>

            <p>Die Idee von Innovation Tokens besteht darin, dass ein Team für die Umsetzung einer bestimmten
                Anforderung nur eine begrenzte Anzahl an Tokens zur Verfügung hat. Die genaue Anzahl hängt von den
                Fähigkeiten und der Einsatzbereitschaft des Teams und der Organisation ab. Die Anzahl der Tokens hängt
                aber nicht vom Umfang der Anforderung ab. Wenn die Anforderung groß ist, war es in unseren Projekten
                bisher nie effektiv, diese mit noch mehr Technologie zu erschlagen. Dies führte eher zum gegenteiligen
                Effekt. Des Weiteren haben wir auch noch kein Team erlebt, das mehr als fünf Tokens in einer Phase
                eingesetzt hat. In der Regel sollten Teams mit drei Innovation Tokens pro Projekt auskommen.</p>

            <blockquote class="pullquote">
                An dieser Stelle kommt oft die Frage auf: Verspiele ich nicht eine Chance, wenn ich Innovation so stark
                begrenze?
            </blockquote>

            <p>Nein, denn wir wollen die Anzahl der gleichzeitig eingeführten Neuerungen auf diejenigen begrenzen, von
                denen wir uns den größten Mehrwert für unsere Produkte oder unseren Business Value-Versprechen. Wir
                können drei wesentliche Punkte festhalten, die die Notwendigkeit unterstreichen, die Anzahl gleichzeitig
                neu eingeführter Technologien zu begrenzen:</p>

            <h3 id="ballast">Kognitiven Ballast vermeiden</h3>

            <p>Auch kognitiven Ballast sollten wir vermeiden. Als kognitiven Ballast bezeichnen wir Aufgaben, die wir
                bei der Einführung neuer Technologien implizit mit aufgebürdet bekommen. Es gibt schon Unit-Tests für
                die Anwendung, aber wie schreiben wir Unit-Tests für diese neue Technologie? Wir haben Monitoring für
                unser System, aber wie muss es angepasst werden, wenn wir die neue Technologie einführen? Was muss ein
                Entwickler wissen, um überhaupt anfangen zu können die neue Technologie zu nutzen? Wie verändern sich
                dadurch die Folgeprozesse?</p>

            <figure>
                <img src="http://via.placeholder.com/675x369" alt="Bild Groß" />
                <figcaption>
                    All diese Themen sind kognitiver Ballast, der mitgetragen werden muss und nicht oder nur indirekt
                    zum Erreichen des Ziels beiträgt.
                </figcaption>
            </figure>

            <p>All diese Themen sind kognitiver Ballast, der mitgetragen werden muss und nicht oder nur indirekt zum
                Erreichen des Ziels beiträgt. Jede Firma, jedes Team kann nur eine bestimmte Menge kognitiven Ballast
                tragen, bevor vielleicht wichtige Punkte runterfallen und vergessen werden. Wie groß diese Menge in
                einem Team gerade ist, lässt sich schwer messen. Was aber klar ist: Dass ein Thema runtergefallen ist,
                bemerken wir meist erst dadurch, dass es uns schmerzhaft auf die Füße fällt.</p>

            <h3 id="fokus">Fokus auf die Wertschöpfung legen</h3>

            <p>Wertschöpfung findet statt, wenn unsere Änderung oder das neue Feature in unserem Produktionssystem
                genutzt wird. Dementsprechend sollte es unser Anliegen sein, die Projektziele an dieser Wertschöpfung
                und den fachlichen Zielen zu orientieren, damit das Projektteam diese in technische Detailentscheidungen
                immer einbezieht – wie der Einführung neuer Technologien. Wenn bei der Definition der Projektziele die
                fachlichen Ziele nicht transparent sind und nicht klar ist, wie der Mehrwert am Ende gemessen wird, kann
                dies dazu führen, dass unbewusst Entscheidungen getroffen werden, die gegen unsere fachlichen Ziele
                laufen.</p>

            <blockquote class="superquote">
                <span class="superquote__zigzag"></span>
                <p>Wertschöpfung findet statt, wenn unsere Änderung oder das neue Feature in unserem Produktionssystem
                    genutzt wird.</p>
                <div itemscope itemtype="http://schema.org/Person">
                    <cite class="superquote__author" itemprop="name">Heribert Innoq</cite>
                    <span class="superquote__role" itemprop="jobTitle">Senior Consultant</span>
                </div>
            </blockquote>

            <p>Der Endkunde zahlt nicht mehr Geld für unsere Produkte, nur weil unsere Protokollevents per TCP in eine
                zentrale ElasticSearch-Datenbank geschrieben werden, anstatt in eine Datei auf der Festplatte. Wie hilft
                das dem Kunden? Wo trägt diese Änderung zur Wertschöpfung bei? Wird das System dadurch stabiler? Sinken
                die Wartungskosten? Können potenzielle Fehlerszenarien früher entdeckt und behoben werden, bevor der
                Kunde davon betroffen ist? Die Aufgabe des Entwicklungsteams ist es, mit ihrer Arbeit zur Wertschöpfung
                ihres Unternehmens beizutragen. Und unter <code> puts "Hello World"</code> diesem Gesichtspunkt sollten
                wir auch unsere Innovation Tokens einsetzen.</p>

            <p>Bei der Definition der Ziele sollte unser Fokus auf den so genannten Differentiatoren liegen, also das zu
                verbessern, was uns von unseren Mitbewerbern abhebt. Dort wollen wir die Mehrheit unserer Zeit
                verbringen, nicht im <a href="https://leanpub.com/37things">so genannten Parity-Sektor</a>, in dem für
                uns und unsere Mitbewerber Gleichheit besteht. Vor diesem Hintergrund kann beispielsweise das beste
                Werkzeug für eine Aufgabe auch ein Altbekanntes sein. Dies ist der Fall, wenn wir die Aufgabe damit
                effektiv erledigen können und das Werkzeug außerdem so gut kennen, dass sich die entstehenden Mehrkosten
                sehr gut abschätzen lassen.</p>

            <h3>So werden die Tokens eingesetzt</h3>

            <p>Nehmen wir an, wir sind in einem Team mit JavaScript-Entwicklern und sollen eine neue Webanwendung
                schreiben. Das Team hat bisher gute Ergebnisse mit dem JavaScript-Web-Framework Express.js erzielt, das
                im Node.js-Ökosystem weit verbreitet ist. Nun möchten die Kollegen aber auf das Framework hapi wechseln,
                weil es einige Expertenfeatures mitbringt. Hierfür müsste das Team ein Innovation Token ausgeben, da es
                sich um einen invasiven Austausch handelt, durch den die Vorgehensweise bei der Entwicklung verändert
                wird und weite Teile der Anwendung umgebaut werden müssen. In Konzeption, Test und Betrieb sollten die
                Veränderungen nicht oder nur marginal zu spüren sein.</p>

            <blockquote class="blockquote">
                "Wichtig ist hierbei, dass die Einführung dieser neuen Technologie eine Mehrheitsentscheidung des Teams
                ist und dass diese Entwurfsentscheidung sowie die Gründe und Alternativen dieser Entscheidung
                schriftlich festgehalten werden(<a href="http://www.arc42.de/template/struktur.html">arc42 Kapitel 9</a>
                ). Auf diese Weise ist nicht nur für Außenstehende, beispielsweise andere Teams oder Auditoren, sondern
                auch für das Team selbst nach ein paar Monaten noch klar ersichtlich, warum die Entscheidung so
                getroffen wurde. So kann das Team zu einem späteren Zeitpunkt die Kriterien ansehen und gegebenenfalls
                feststellen, dass sich die Rahmenbedingungen geändert haben und die Entscheidung zu Gunsten einer
                Alternative revidiert werden sollte."
            </blockquote>

            <p>In dem Moment, in dem eine Entwurfsentscheidung über die Teamgrenzen hinaus geht, also beispielsweise
                auch Auswirkungen auf den Betrieb der Anwendung hat, muss das Team hierfür zwei Innovation Tokens
                ausgeben. Dies wäre bei der Einführung einer neuen Datenbanktechnologie der Fall, die noch nicht im
                Unternehmen vorhanden ist. Der Grund hierfür ist, dass dies nicht nur Aufwände und Risiken in unserem
                Team erzeugt, sondern eben auch in mindestens einem anderen Team. Unser Operationsteam muss sich bei der
                Einführung beispielsweise von Cassandra mit Themen wie Clusterbetrieb, Datensicherung und
                -wiederherstellung, dem Monitoring und dem Verhalten der Datenbank bei <a href="https://en.m.wikipedia.org/wiki/Network_partition">Network Partitions beschäftigen</a>, damit
                das Entwicklungsteam die Datenbank überhaupt benutzen kann.</p>

            <info-box>
                <div class="infobox__teaser">
                    <div class="infobox__teaser__left">
                        <h6 class="infobox__teaser__heading">Weitere Informationen</h6>
                        <i class="icon icon-info"></i>
                    </div>
                    <div class="infobox__teaser__right">
                        <i class="icon infobox__teaser__chevron"></i>
                    </div>
                </div>

                <aside class="infobox__content">
                    <div class="infobox__content__box">
                        <p class="infobox__content__text">
                            Bei der Definition der Ziele sollte unser Fokus auf den so genannten Differentiatoren
                            liegen, also das zu verbessern, was uns von unseren Mitbewerbern abhebt. Dort wollen wir die
                            Mehrheit unserer Zeit verbringen, nicht im <a href="https://leanpub.com/37things">so
                                genannten Parity-Sektor</a>, in dem für uns und unsere Mitbewerber Gleichheit besteht.
                            Vor diesem Hintergrund kann beispielsweise das beste Werkzeug für eine Aufgabe auch ein
                            Altbekanntes sein. Dies ist der Fall, wenn wir die Aufgabe damit effektiv erledigen können
                            und das Werkzeug außerdem so gut kennen, dass sich die entstehenden Mehrkosten sehr gut
                            abschätzen lassen.
                        </p>
                    </div>
                </aside>
            </info-box>

            <h3>Ein konkretes Beispielprojekt</h3>

            <p>Letztlich steht und fällt die Idee der Innovation Tokens mit der Akzeptanz bei den Teammitgliedern. Was,
                wenn die Teams die Gründe für diese Einschränkung nicht verstehen? Oder schlimmer noch, sie vermuten als
                Ursache die vermeintliche Inkompetenz eines anderen Teams mit den neuen Technologien umzugehen und
                beschuldigen das andere Team, sie auszubremsen, anstatt dieses Team bei der Aufgabe zu unterstützen. Da
                ich allerdings ein großer Freund von kleinen Experimenten bin und davon, Dinge auszuprobieren, anstatt
                sie tot zu diskutieren, haben wir das Konzept in einem kleinen Projekt angewendet.</p>

            <p>Der Auftrag des Projekts war es, eine Webanwendung als Microservice zu erstellen <a href="#fn:1" id="fnref:1" title="see footnote" class="footnote">[1]</a>. Im Entwicklungsteam herrschten von
                Anfang an sehr unterschiedliche Vorstellungen davon, welche Technologien benötigt würden. Nahezu jedes
                Teammitglied schlug andere Technologien vor und die meisten beharrten darauf, dass diese unbedingt
                notwendig seien. Wir merkten schnell, dass wir so nicht weiterkamen. Wir mussten ein gemeinsames
                Verständnis dafür erarbeiten, welche Technologie uns an welcher Stelle wie stark helfen konnte, wie viel
                Aufwand die Einführung bedeutete und welche Alternativen es gab. Deshalb sollte zunächst jeder seine
                eigenen Vorschläge dem Team schriftlich vorstellen und dabei folgende Fragen beantworten:</p>

            <figure>
                <table class="table">
                    <thead>
                        <tr>
                            <th>Merkmal</th>
                            <th>Untermerkmal</th>
                            <th>Szenario</th>
                            <th>Priorität</th>
                        </tr>
                    </thead>
                    <tbody>
                        <tr>
                            <td>Zuverlässigkeit</td>
                            <td>Robustheit</td>
                            <td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis
                                ohne Absturz.</td>
                            <td>B</td>
                        </tr>
                        <tr>
                            <td></td>
                            <td>Robustheit</td>
                            <td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis
                                ohne Absturz.</td>
                            <td>A</td>
                        </tr>
                        <tr>
                            <td>Zuverlässigkeit</td>
                            <td>Datenintegerität</td>
                            <td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis
                                ohne Absturz.</td>
                            <td>A</td>
                        </tr>
                        <tr>
                            <td>Performance</td>
                            <td>Benutzeranzahl</td>
                            <td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis
                                ohne Absturz.</td>
                            <td>B</td>
                        </tr>
                    </tbody>
                </table>
                <figcaption>
                    Dies ist eine Tabelle mit wichtigem Inhalt
                </figcaption>
            </figure>
            <p>Interessant war insbesondere bei den Antworten zu Frage 1, dass hier Probleme genannt wurden, die vorher
                nie diskutiert worden waren. Dies war ein Gewinn für das Projekt, denn es führte zu Schritt 0: Probleme
                und Herausforderungen explizit machen. Dieses Ergebnis half den anderen Teammitgliedern, die Beweggründe
                des Vorschlagenden zu verstehen und einschätzen zu können. Anschließend konnten wir im Team
                Technologievorschläge zusammenfassen und über die beste Alternative abstimmen. Allerdings konnten wir
                die Liste immer noch nicht auf die gewünschte Anzahl von nur drei Technologien verkürzen.</p>

            <p>Um dieses Ziel letztlich doch zu erreichen, schlug unser Projektleiter eine geheime Abstimmung vor. Jeder
                von uns wählte die aus seiner Sicht wichtigsten drei Technologien aus und schickte seine Auswahl an
                unseren Projektleiter. Dieser addierte die Stimmen und stellte uns das Ergebnis in einem Folgetermin
                vor. So reduzierten wir eine Liste von 28 Technologien auf sechs, wobei zwei Technologien ganz vorne
                lagen. Da wir uns hier nicht auf eine dritte Technologie einigen konnten, beschlossen wir, zunächst mit
                den zwei neuen sowie den vorhandenen Technologien zu starten. Die Entscheidung für die dritte
                Technologie wollten wir erst später treffen, wenn wir an einen Punkt kommen sollten, an dem wir unsere
                Herausforderungen nicht mehr lösen könnten. Dieser Fall trat in diesem Projekt jedoch nie ein.</p>

            <p>Rückblickend können wir sagen, dass wir die Probleme vermutlich auch über Umwege ganz ohne neue
                Technologien hätten lösen können. Hier wären dann aber die nicht zu unterschätzenden Faktoren
                Motivation, Teamgefühl und vor allem die Weiterbildung zu kurz gekommen. Dies kann sich unserer
                Erfahrung nach mittelfristig negativ auf die Produktivität auswirken, wodurch dann wirklich
                Wettbewerbsnachteile entstehen können.</p>
        </section>
        <section class="center footnote-section">
            <div class="footnote-section__headline__container">
                <h3 class="footnote-section__headline">Quellenangaben</h3>
            </div>

            <div class="footnotes">
                <ol class="footnotes__list">
                    <li id="fn:1">
                        <p>
                            Lorem gibson courier long-chain hydrocarbons realism bomb otaku SIN tiger-team macroform
                            node dermatrodes tower Chiba City pre-table DIY chrome Mole IX camera People of Importance.
                            Lorem gibson temperfoam sunglasses assault systema tower order-flow screen macroform node
                            tanto sprawl icebreaker drone sentient Mole IX Mycotoxin Dex.
                            <a href="#fnref:1" title="return to article">&nbsp;</a>
                        </p>
                    </li>
                    <li id="fn:2">
                        <p>
                            Lorem gibson modem hotdog market corrupted Metro Holografix sprawl EMP.
                        </p>
                        <p>
                            Lorem gibson Kowloon man House of the Blue Lights Turing Registry wristwatch geodesic
                            nodality new yen House of the Blue Lights memory refrigerator advert free-market.
                            <a href="#fnref:2" title="return to article">&nbsp;</a>
                        </p>
                    </li>
                    <li id="fn:3">
                        <p>
                            Eberhard Wolff: Microservices: Grundlagen flexibler Softwarearchitekturen, dpunkt.verlag,
                            2015, ISBN 978–3864903137
                            <a href="#fnref:3" title="return to article">&nbsp;</a>
                        </p>
                    </li>
                    <li id="fn:4">
                        <p><a href="http://www.vasulka.org/archive/Institutions1/EATnews.pdf">http://www.vasulka.org/archive/Institutions1/EATnews.pdf</a>
                            <a href="#fnref:1" title="return to body" class="reversefootnote">&nbsp;</a>
                        </p>
                    </li>
                </ol>
            </div>
        </section>
    </article>

    <section class="breakout conclusion">
        <div class="breakout__content">
            <h1 class="conclusion-headline">Fazit</h1>
            <h3 class="conclusion-subheadline">Kurz auf den Punkt gebracht</h3>
            <p class="conclusion-text">
                Innovation Tokens sind ein einfach verständlicher <a href="https://de.wikipedia.org/wiki/Ansatz">Ansatz</a>, um das richtige Maß an neuen Technologien in
                Softwareentwicklungsprojekten zu finden. Projektverantwortliche und Teams bekommen hierbei ein
                Hilfsmittel an die Hand, das eine Selbstkontrolle und Fokussierung auf das Notwendige ermöglicht,
                anstatt einem Team überladene Genehmigungsprozesse oder lähmende Regularien aufzubürden. Kurz: Bei
                richtiger Anwendung fördern sie den gesunden Menschenverstand und die Besinnung auf die
                Wertschöpfungsziele.
            </p>
            <p class="conclusion-text"><strong>Kurz:</strong> Bei richtiger Anwendung fördern sie den gesunden
                Menschenverstand und die Besinnung auf die Wertschöpfungsziele.</p>
        </div>
    </section>

    <section class="breakout tag-section">
        <h3 class="tag-section__headline">TAGS</h3>
        <div class="tag-section__container">
            <ul class="tag-list">
                <li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=microservices">Microservices</a></li>
                <li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=business+technology">Business Technology</a></li>
                <li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=architecture">Architecture</a></li>
                <li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=organization">Organization</a></li>
                <li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=innovation">Innovation</a>
                </li>
                <li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=project+management">Project
                        Management</a></li>
            </ul>
        </div>
    </section>

    <aside class="page-layout--grid">
        <section class="center share-section">
            <span class="icon-svg icon-arrow-long-down icon--brand-secondary"></span>
            <h3 class="share-section__heading">Share on</h3>
            <ul class="share-section__list">
                <li>
                    <a class="share-section__link" target="_blank" href="">
                        <span class="icon-svg icon-facebook icon--brand-secondary"></span>
                    </a>
                </li>
                <li>
                    <a class="share-section__link" target="_blank" href="">
                        <span class="icon-svg icon-twitter icon--brand-secondary"></span>
                    </a>
                </li>
                <li>
                    <a class="share-section__link" href="">
                        <span class="icon-svg icon-email icon--brand-secondary"></span>
                    </a>
                </li>
            </ul>
        </section>
    </aside>

    <div class="dark-background">
        <div class="page-layout-xl--default">
            <footer class="footer">FOOTER</footer>
        </div>
    </div>
</main>
<header class="standard-header" style="background-image: url({{ path '/assets/bg-images/general/visual-trainings-01.jpg' }}); background-color: var(--overlay-standard-color);">
    <h1 class="standard-header__title">Hey ho, let's go</h1>
    <h2 class="standard-header__subtitle">...</h2>
    <div class="standard-header__intro">
        <span class="standard-header__intro__label">fintech</span>
        <div class="standard-header__intro__text">
            Zu oft werden in Softwareprojekten zu viele neue Dinge gleichzeitig
            ausprobiert, ohne dass der Business Value erkennbar wäre- und vor allem,
            ohne die Risiken vorher abzuschätzen. Eine Möglichkeit, die unnötige
            Technologieüberflutung zu vermeiden, sind Innovation Tokens. Mit diesen
            lassen sich Innovationen in geregeltere Bahnen lenken und bieten eine
            Grundlage für weniger emotionale Technologiediskussionen.
        </div>
        <div class="content-separator content-seperator--inverted">
            <time class="content-separator__date date" datetime="2017-06-26">26. Juni 2017</time>
            <hr class="content-separator__separator" />
            <time class="content-separator__duration duration" datetime="P8M">8 Min. Lesedauer</time>
        </div>
    </div>
</header>
<main role="main">
    <article class="page-layout--grid">
        <aside class="left toc">
            <h3 class="toc__heading">Inhalt</h3>
            <ol class="toc__list">
                <li><a class="toc__anchor" href="#dilemma">Das Dilemma: Innovation vs. Chaos</a></li>
                <li><a class="toc__anchor" href="#idee">Die Idee hinter Innovation Tokens</a></li>
                <li><a class="toc__anchor" href="#unbekannt">An die unbekannten Unbekannten denken und besonders darauf
                        achten</a></li>
                <li><a class="toc__anchor" href="#ballast">Kognitiven Ballast vermeiden</a></li>
                <li><a class="toc__anchor" href="#fokus">Fokus auf die Wertschöpfung legen</a></li>
                <li><a class="toc__anchor" href="#fazit">Fazit</a></li>
            </ol>
        </aside>

        <section class="center">
            <h3 id="dilemma">Das Dilemma: Innovation vs. Chaos</h3>

            <p>Eine neue Technologie ins Unternehmen oder Projekt einzubringen, verursacht Kosten. Aber sind wir uns
                wirklich im Klaren darüber, über welche Kosten wir hier sprechen? Wenn wir ein Team von erfahrenen
                Java-Entwicklern haben, wird der Vorschlag, neue Anforderungen an unsere Anwendung mit Python
                umzusetzen, vermutlich Stirnrunzeln hervorrufen. Denn uns wird relativ schnell bewusst, dass die
                Anwendung dadurch komplexer werden würde. Wir würden uns fragen, ob das Team dies handhaben kann und ob
                unser Betrieb dem gewachsen ist.</p>

            <h3 id="idee">Die Idee hinter Innovation Tokens</h3>

            <p>Die Idee von Innovation Tokens besteht darin, dass ein Team für die Umsetzung einer bestimmten
                Anforderung nur eine begrenzte Anzahl an Tokens zur Verfügung hat. Die genaue Anzahl hängt von den
                Fähigkeiten und der Einsatzbereitschaft des Teams und der Organisation ab. Die Anzahl der Tokens hängt
                aber nicht vom Umfang der Anforderung ab. Wenn die Anforderung groß ist, war es in unseren Projekten
                bisher nie effektiv, diese mit noch mehr Technologie zu erschlagen. Dies führte eher zum gegenteiligen
                Effekt. Des Weiteren haben wir auch noch kein Team erlebt, das mehr als fünf Tokens in einer Phase
                eingesetzt hat. In der Regel sollten Teams mit drei Innovation Tokens pro Projekt auskommen.</p>

            <blockquote class="pullquote">
                An dieser Stelle kommt oft die Frage auf: Verspiele ich nicht eine Chance, wenn ich Innovation so stark
                begrenze?
            </blockquote>

            <p>Nein, denn wir wollen die Anzahl der gleichzeitig eingeführten Neuerungen auf diejenigen begrenzen, von
                denen wir uns den größten Mehrwert für unsere Produkte oder unseren Business Value-Versprechen. Wir
                können drei wesentliche Punkte festhalten, die die Notwendigkeit unterstreichen, die Anzahl gleichzeitig
                neu eingeführter Technologien zu begrenzen:</p>

            <h3 id="ballast">Kognitiven Ballast vermeiden</h3>

            <p>Auch kognitiven Ballast sollten wir vermeiden. Als kognitiven Ballast bezeichnen wir Aufgaben, die wir
                bei der Einführung neuer Technologien implizit mit aufgebürdet bekommen. Es gibt schon Unit-Tests für
                die Anwendung, aber wie schreiben wir Unit-Tests für diese neue Technologie? Wir haben Monitoring für
                unser System, aber wie muss es angepasst werden, wenn wir die neue Technologie einführen? Was muss ein
                Entwickler wissen, um überhaupt anfangen zu können die neue Technologie zu nutzen? Wie verändern sich
                dadurch die Folgeprozesse?</p>

            <figure>
                <img src="http://via.placeholder.com/675x369" alt="Bild Groß" />
                <figcaption>
                    All diese Themen sind kognitiver Ballast, der mitgetragen werden muss und nicht oder nur indirekt
                    zum Erreichen des Ziels beiträgt.
                </figcaption>
            </figure>

            <p>All diese Themen sind kognitiver Ballast, der mitgetragen werden muss und nicht oder nur indirekt zum
                Erreichen des Ziels beiträgt. Jede Firma, jedes Team kann nur eine bestimmte Menge kognitiven Ballast
                tragen, bevor vielleicht wichtige Punkte runterfallen und vergessen werden. Wie groß diese Menge in
                einem Team gerade ist, lässt sich schwer messen. Was aber klar ist: Dass ein Thema runtergefallen ist,
                bemerken wir meist erst dadurch, dass es uns schmerzhaft auf die Füße fällt.</p>

            <h3 id="fokus">Fokus auf die Wertschöpfung legen</h3>

            <p>Wertschöpfung findet statt, wenn unsere Änderung oder das neue Feature in unserem Produktionssystem
                genutzt wird. Dementsprechend sollte es unser Anliegen sein, die Projektziele an dieser Wertschöpfung
                und den fachlichen Zielen zu orientieren, damit das Projektteam diese in technische Detailentscheidungen
                immer einbezieht – wie der Einführung neuer Technologien. Wenn bei der Definition der Projektziele die
                fachlichen Ziele nicht transparent sind und nicht klar ist, wie der Mehrwert am Ende gemessen wird, kann
                dies dazu führen, dass unbewusst Entscheidungen getroffen werden, die gegen unsere fachlichen Ziele
                laufen.</p>

            <blockquote class="superquote">
                <span class="superquote__zigzag"></span>
                <p>Wertschöpfung findet statt, wenn unsere Änderung oder das neue Feature in unserem Produktionssystem
                    genutzt wird.</p>
                <div itemscope itemtype="http://schema.org/Person">
                    <cite class="superquote__author" itemprop="name">Heribert Innoq</cite>
                    <span class="superquote__role" itemprop="jobTitle">Senior Consultant</span>
                </div>
            </blockquote>

            <p>Der Endkunde zahlt nicht mehr Geld für unsere Produkte, nur weil unsere Protokollevents per TCP in eine
                zentrale ElasticSearch-Datenbank geschrieben werden, anstatt in eine Datei auf der Festplatte. Wie hilft
                das dem Kunden? Wo trägt diese Änderung zur Wertschöpfung bei? Wird das System dadurch stabiler? Sinken
                die Wartungskosten? Können potenzielle Fehlerszenarien früher entdeckt und behoben werden, bevor der
                Kunde davon betroffen ist? Die Aufgabe des Entwicklungsteams ist es, mit ihrer Arbeit zur Wertschöpfung
                ihres Unternehmens beizutragen. Und unter <code> puts "Hello World"</code> diesem Gesichtspunkt sollten
                wir auch unsere Innovation Tokens einsetzen.</p>

            <p>Bei der Definition der Ziele sollte unser Fokus auf den so genannten Differentiatoren liegen, also das zu
                verbessern, was uns von unseren Mitbewerbern abhebt. Dort wollen wir die Mehrheit unserer Zeit
                verbringen, nicht im <a href="https://leanpub.com/37things">so genannten Parity-Sektor</a>, in dem für
                uns und unsere Mitbewerber Gleichheit besteht. Vor diesem Hintergrund kann beispielsweise das beste
                Werkzeug für eine Aufgabe auch ein Altbekanntes sein. Dies ist der Fall, wenn wir die Aufgabe damit
                effektiv erledigen können und das Werkzeug außerdem so gut kennen, dass sich die entstehenden Mehrkosten
                sehr gut abschätzen lassen.</p>

            <h3>So werden die Tokens eingesetzt</h3>

            <p>Nehmen wir an, wir sind in einem Team mit JavaScript-Entwicklern und sollen eine neue Webanwendung
                schreiben. Das Team hat bisher gute Ergebnisse mit dem JavaScript-Web-Framework Express.js erzielt, das
                im Node.js-Ökosystem weit verbreitet ist. Nun möchten die Kollegen aber auf das Framework hapi wechseln,
                weil es einige Expertenfeatures mitbringt. Hierfür müsste das Team ein Innovation Token ausgeben, da es
                sich um einen invasiven Austausch handelt, durch den die Vorgehensweise bei der Entwicklung verändert
                wird und weite Teile der Anwendung umgebaut werden müssen. In Konzeption, Test und Betrieb sollten die
                Veränderungen nicht oder nur marginal zu spüren sein.</p>

            <blockquote class="blockquote">
                "Wichtig ist hierbei, dass die Einführung dieser neuen Technologie eine Mehrheitsentscheidung des Teams
                ist und dass diese Entwurfsentscheidung sowie die Gründe und Alternativen dieser Entscheidung
                schriftlich festgehalten werden(<a href="http://www.arc42.de/template/struktur.html">arc42 Kapitel 9</a>
                ). Auf diese Weise ist nicht nur für Außenstehende, beispielsweise andere Teams oder Auditoren, sondern
                auch für das Team selbst nach ein paar Monaten noch klar ersichtlich, warum die Entscheidung so
                getroffen wurde. So kann das Team zu einem späteren Zeitpunkt die Kriterien ansehen und gegebenenfalls
                feststellen, dass sich die Rahmenbedingungen geändert haben und die Entscheidung zu Gunsten einer
                Alternative revidiert werden sollte."
            </blockquote>

            <p>In dem Moment, in dem eine Entwurfsentscheidung über die Teamgrenzen hinaus geht, also beispielsweise
                auch Auswirkungen auf den Betrieb der Anwendung hat, muss das Team hierfür zwei Innovation Tokens
                ausgeben. Dies wäre bei der Einführung einer neuen Datenbanktechnologie der Fall, die noch nicht im
                Unternehmen vorhanden ist. Der Grund hierfür ist, dass dies nicht nur Aufwände und Risiken in unserem
                Team erzeugt, sondern eben auch in mindestens einem anderen Team. Unser Operationsteam muss sich bei der
                Einführung beispielsweise von Cassandra mit Themen wie Clusterbetrieb, Datensicherung und
                -wiederherstellung, dem Monitoring und dem Verhalten der Datenbank bei <a
                    href="https://en.m.wikipedia.org/wiki/Network_partition">Network Partitions beschäftigen</a>, damit
                das Entwicklungsteam die Datenbank überhaupt benutzen kann.</p>

            <info-box>
                <div class="infobox__teaser">
                    <div class="infobox__teaser__left">
                        <h6 class="infobox__teaser__heading">Weitere Informationen</h6>
                        <i class="icon icon-info"></i>
                    </div>
                    <div class="infobox__teaser__right">
                        <i class="icon infobox__teaser__chevron"></i>
                    </div>
                </div>

                <aside class="infobox__content">
                    <div class="infobox__content__box">
                        <p class="infobox__content__text">
                            Bei der Definition der Ziele sollte unser Fokus auf den so genannten Differentiatoren
                            liegen, also das zu verbessern, was uns von unseren Mitbewerbern abhebt. Dort wollen wir die
                            Mehrheit unserer Zeit verbringen, nicht im <a href="https://leanpub.com/37things">so
                                genannten Parity-Sektor</a>, in dem für uns und unsere Mitbewerber Gleichheit besteht.
                            Vor diesem Hintergrund kann beispielsweise das beste Werkzeug für eine Aufgabe auch ein
                            Altbekanntes sein. Dies ist der Fall, wenn wir die Aufgabe damit effektiv erledigen können
                            und das Werkzeug außerdem so gut kennen, dass sich die entstehenden Mehrkosten sehr gut
                            abschätzen lassen.
                        </p>
                    </div>
                </aside>
            </info-box>

            <h3>Ein konkretes Beispielprojekt</h3>

            <p>Letztlich steht und fällt die Idee der Innovation Tokens mit der Akzeptanz bei den Teammitgliedern. Was,
                wenn die Teams die Gründe für diese Einschränkung nicht verstehen? Oder schlimmer noch, sie vermuten als
                Ursache die vermeintliche Inkompetenz eines anderen Teams mit den neuen Technologien umzugehen und
                beschuldigen das andere Team, sie auszubremsen, anstatt dieses Team bei der Aufgabe zu unterstützen. Da
                ich allerdings ein großer Freund von kleinen Experimenten bin und davon, Dinge auszuprobieren, anstatt
                sie tot zu diskutieren, haben wir das Konzept in einem kleinen Projekt angewendet.</p>

            <p>Der Auftrag des Projekts war es, eine Webanwendung als Microservice zu erstellen <a href="#fn:1"
                    id="fnref:1" title="see footnote" class="footnote">[1]</a>. Im Entwicklungsteam herrschten von
                Anfang an sehr unterschiedliche Vorstellungen davon, welche Technologien benötigt würden. Nahezu jedes
                Teammitglied schlug andere Technologien vor und die meisten beharrten darauf, dass diese unbedingt
                notwendig seien. Wir merkten schnell, dass wir so nicht weiterkamen. Wir mussten ein gemeinsames
                Verständnis dafür erarbeiten, welche Technologie uns an welcher Stelle wie stark helfen konnte, wie viel
                Aufwand die Einführung bedeutete und welche Alternativen es gab. Deshalb sollte zunächst jeder seine
                eigenen Vorschläge dem Team schriftlich vorstellen und dabei folgende Fragen beantworten:</p>

            <figure>
                <table class="table">
                    <thead>
                        <tr>
                            <th>Merkmal</th>
                            <th>Untermerkmal</th>
                            <th>Szenario</th>
                            <th>Priorität</th>
                        </tr>
                    </thead>
                    <tbody>
                        <tr>
                            <td>Zuverlässigkeit</td>
                            <td>Robustheit</td>
                            <td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis
                                ohne Absturz.</td>
                            <td>B</td>
                        </tr>
                        <tr>
                            <td></td>
                            <td>Robustheit</td>
                            <td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis
                                ohne Absturz.</td>
                            <td>A</td>
                        </tr>
                        <tr>
                            <td>Zuverlässigkeit</td>
                            <td>Datenintegerität</td>
                            <td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis
                                ohne Absturz.</td>
                            <td>A</td>
                        </tr>
                        <tr>
                            <td>Performance</td>
                            <td>Benutzeranzahl</td>
                            <td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis
                                ohne Absturz.</td>
                            <td>B</td>
                        </tr>
                    </tbody>
                </table>
                <figcaption>
                    Dies ist eine Tabelle mit wichtigem Inhalt
                </figcaption>
            </figure>
            <p>Interessant war insbesondere bei den Antworten zu Frage 1, dass hier Probleme genannt wurden, die vorher
                nie diskutiert worden waren. Dies war ein Gewinn für das Projekt, denn es führte zu Schritt 0: Probleme
                und Herausforderungen explizit machen. Dieses Ergebnis half den anderen Teammitgliedern, die Beweggründe
                des Vorschlagenden zu verstehen und einschätzen zu können. Anschließend konnten wir im Team
                Technologievorschläge zusammenfassen und über die beste Alternative abstimmen. Allerdings konnten wir
                die Liste immer noch nicht auf die gewünschte Anzahl von nur drei Technologien verkürzen.</p>

            <p>Um dieses Ziel letztlich doch zu erreichen, schlug unser Projektleiter eine geheime Abstimmung vor. Jeder
                von uns wählte die aus seiner Sicht wichtigsten drei Technologien aus und schickte seine Auswahl an
                unseren Projektleiter. Dieser addierte die Stimmen und stellte uns das Ergebnis in einem Folgetermin
                vor. So reduzierten wir eine Liste von 28 Technologien auf sechs, wobei zwei Technologien ganz vorne
                lagen. Da wir uns hier nicht auf eine dritte Technologie einigen konnten, beschlossen wir, zunächst mit
                den zwei neuen sowie den vorhandenen Technologien zu starten. Die Entscheidung für die dritte
                Technologie wollten wir erst später treffen, wenn wir an einen Punkt kommen sollten, an dem wir unsere
                Herausforderungen nicht mehr lösen könnten. Dieser Fall trat in diesem Projekt jedoch nie ein.</p>

            <p>Rückblickend können wir sagen, dass wir die Probleme vermutlich auch über Umwege ganz ohne neue
                Technologien hätten lösen können. Hier wären dann aber die nicht zu unterschätzenden Faktoren
                Motivation, Teamgefühl und vor allem die Weiterbildung zu kurz gekommen. Dies kann sich unserer
                Erfahrung nach mittelfristig negativ auf die Produktivität auswirken, wodurch dann wirklich
                Wettbewerbsnachteile entstehen können.</p>
        </section>
        <section class="center footnote-section">
            <div class="footnote-section__headline__container">
                <h3 class="footnote-section__headline">Quellenangaben</h3>
            </div>

            <div class="footnotes">
                <ol class="footnotes__list">
                    <li id="fn:1">
                        <p>
                            Lorem gibson courier long-chain hydrocarbons realism bomb otaku SIN tiger-team macroform
                            node dermatrodes tower Chiba City pre-table DIY chrome Mole IX camera People of Importance.
                            Lorem gibson temperfoam sunglasses assault systema tower order-flow screen macroform node
                            tanto sprawl icebreaker drone sentient Mole IX Mycotoxin Dex.
                            <a href="#fnref:1" title="return to article">&nbsp;</a>
                        </p>
                    </li>
                    <li id="fn:2">
                        <p>
                            Lorem gibson modem hotdog market corrupted Metro Holografix sprawl EMP.
                        </p>
                        <p>
                            Lorem gibson Kowloon man House of the Blue Lights Turing Registry wristwatch geodesic
                            nodality new yen House of the Blue Lights memory refrigerator advert free-market.
                            <a href="#fnref:2" title="return to article">&nbsp;</a>
                        </p>
                    </li>
                    <li id="fn:3">
                        <p>
                            Eberhard Wolff: Microservices: Grundlagen flexibler Softwarearchitekturen, dpunkt.verlag,
                            2015, ISBN 978–3864903137
                            <a href="#fnref:3" title="return to article">&nbsp;</a>
                        </p>
                    </li>
                    <li id="fn:4">
                        <p><a
                                href="http://www.vasulka.org/archive/Institutions1/EATnews.pdf">http://www.vasulka.org/archive/Institutions1/EATnews.pdf</a>
                            <a href="#fnref:1" title="return to body" class="reversefootnote">&nbsp;</a></p>
                    </li>
                </ol>
            </div>
        </section>
    </article>

    <section class="breakout conclusion">
        <div class="breakout__content">
            <h1 class="conclusion-headline">Fazit</h1>
            <h3 class="conclusion-subheadline">Kurz auf den Punkt gebracht</h3>
            <p class="conclusion-text">
                Innovation Tokens sind ein einfach verständlicher <a
                    href="https://de.wikipedia.org/wiki/Ansatz">Ansatz</a>, um das richtige Maß an neuen Technologien in
                Softwareentwicklungsprojekten zu finden. Projektverantwortliche und Teams bekommen hierbei ein
                Hilfsmittel an die Hand, das eine Selbstkontrolle und Fokussierung auf das Notwendige ermöglicht,
                anstatt einem Team überladene Genehmigungsprozesse oder lähmende Regularien aufzubürden. Kurz: Bei
                richtiger Anwendung fördern sie den gesunden Menschenverstand und die Besinnung auf die
                Wertschöpfungsziele.
            </p>
            <p class="conclusion-text"><strong>Kurz:</strong> Bei richtiger Anwendung fördern sie den gesunden
                Menschenverstand und die Besinnung auf die Wertschöpfungsziele.</p>
        </div>
    </section>

    <section class="breakout tag-section">
        <h3 class="tag-section__headline">TAGS</h3>
        <div class="tag-section__container">
            <ul class="tag-list">
                <li class="tag-list__item"><a class="tag-list__link"
                        href="/de/timeline/?tag=microservices">Microservices</a></li>
                <li class="tag-list__item"><a class="tag-list__link"
                        href="/de/timeline/?tag=business+technology">Business Technology</a></li>
                <li class="tag-list__item"><a class="tag-list__link"
                        href="/de/timeline/?tag=architecture">Architecture</a></li>
                <li class="tag-list__item"><a class="tag-list__link"
                        href="/de/timeline/?tag=organization">Organization</a></li>
                <li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=innovation">Innovation</a>
                </li>
                <li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=project+management">Project
                        Management</a></li>
            </ul>
        </div>
    </section>

    <aside class="page-layout--grid">
        <section class="center share-section">
            <span class="icon-svg icon-arrow-long-down icon--brand-secondary"></span>
            <h3 class="share-section__heading">Share on</h3>
            <ul class="share-section__list">
                <li>
                    <a class="share-section__link" target="_blank" href="">
                        <span class="icon-svg icon-facebook icon--brand-secondary"></span>
                    </a>
                </li>
                <li>
                    <a class="share-section__link" target="_blank" href="">
                        <span class="icon-svg icon-twitter icon--brand-secondary"></span>
                    </a>
                </li>
                <li>
                    <a class="share-section__link" href="">
                        <span class="icon-svg icon-email icon--brand-secondary"></span>
                    </a>
                </li>
            </ul>
        </section>
    </aside>

    <div class="dark-background">
        <div class="page-layout-xl--default">
            <footer class="footer">FOOTER</footer>
        </div>
    </div>
</main>
{
  "code": "pick(:love) do |something|\n    n.times do\n        result = play(something)\n        result.publish\n    end\nend\n"
}
  • Handle: @case-study-page
  • Preview:
  • Filesystem Path: components/01-pages/case-study-pages/case-study-page/case-study-page.html

No notes defined.