Der Wirtschaftsteil der Süddeutschen Zeitung hat dieses Wochenende einen Aufreisser: „Die Abarbeiter –  Alle beantworten ständig E-Mails oder sitzen in Konferenzen, zentrale Aufgaben erledigen sie irgendwann dazwischen. Das macht unproduktiv und unglücklich. Trotzdem wird konzentrierte Arbeit immer seltener.“

Ertappt.

Hoffentlich merkt das keiner, dass ich genau in diese Falle getappt bin.

Die Wahrscheinlichkeit ist gering, denn die anderen sitzen in derselben Falle.

Natürlich war ich auch am Wochenende aktiv.

Und am Freitag bin ich 100km durch den Hauptferienverkehr hin und zurückgefahren um 10 min produktiv zu sein.

Slow down.

Sonst funktioniert es nur, wenn wir uns alle von der Bildfläche tragen lassen wollen.

Und wie immer: Weniger ist mehr!

Sich zurücknehmen hilft.

Digitalisierung ist wieder eines dieser unsäglichen Buzzwords, das wie so oft unreflektiert gehypt wird. Ich halte es obendrein für ein sehr gefährliches Buzzword, weil es den Fokus falsch setzt: Technik vor Geschäftsmodell. Dabei ist doch die Technik primär Mittel zum Zweck. Selbstverständlich können neue Techniken zu disruptiven Entwicklungen in Geschäftsmodellen führen, aber dennoch sollte man das Pferd nicht von hinten aufziehen.

Und um ehrlich zu sein: Die Werkzeuge der Digitalisierung sind nicht wirklich neu, sie sind nur weitaus mächtiger und allgegenwärtiger geworden. Aber welche Werkzeuge/Möglichkeiten sind das?

(1) Messen, Steuern, Regeln
Nun, wirklich nichts Neues in unserer längst digitalisierten Welt. Zugegeben: Die Auswertungsmöglichkeiten sind gewachsen, womit wir schon beim zweiten Punkt wären:

(2) Business Intelligence
Mit den zunehmend vorhandenen digitalen Daten (1) und mächtigeren Auswertungsmöglichkeiten der eigenen Daten oder selbst der Daten anderer, selbst unserer Mitbewerber (Comptetitive Intelligence) sind die Möglichkeiten der Business Intelligence gewachsen, aber neu sind sie bei Weitem nicht, allerdings in der Kombination mit…

(3) Big Data
…ergeben sich neue Erkenntnisse – auch wenn diese mitunter überschätzt werden. Die Vielzahl der heute verfügbaren Daten lässt uns elementare Grundsätze der Datenverarbeitung immer wieder vergessen: Nach wie vor gilt: Garbage in, Garbage out. Wir müssen also wissen, was wir messen und das nächste Dilemma liefert uns die Scheingenauigkeit: Messungen bis auf drei Kommastellen suggerieren Exaktheit und Wahrheit, nicht-messbare oder nicht gemessene aber relevante Einflussgrößen fliegen hingegen aus unseren Modellen hinaus und wir wundern uns dann, warum unsere Modelle nicht funktionieren. Hier ist weniger oft mehr. Ich plädiere an den gesunden Menschenverstand: Wenn auswerten, dann müssen wir auch wissen was und wo unsere Modellgrenzen liegen.

Kommen wir zu den mehr technologischen Aspekten hinter der Digitalisierung:

(4) Vernetzung
Auch in der Industrie ist Digitalisierung nichts Neues. Computer-gesteuerte Maschinen gibt es seit langem, was aber zunehmend steigt ist der Grad der Vernetzung. Damit hängen Maschinen oder ganze Produktionslinien plötzlich im Internet. Der Kühlschrank kann plötzlich selber bestellen, aber meine Produktionsmaschine ist plötzlich auch anfällig für einen Virenbefall á la Stuxnet. Mit der Vernetzung steigt die Komplexität und die wechselseitige Abhängigkeit.

(5) Virtualisierung
Unser Bild vom Computer ist noch stark geprägt von der physischen Entität eines Rechners, sei es unser Notebook, ein Desktop-PC oder ein Server. Aber zumindest in der Server-Welt haben sich Virtualisierungskonzepte längst durchgesetzt, da ordert man in einem Rechenzentrum nicht mehr (oder nur noch in besonderen Fällen) einen physischen Rechner, sondern stattdessen eine virtuelle Instanz. Zunehmend passiert die Virtualisierung auch nicht mehr im eigenen Haus, sondern wird ausgelagert in die…

(6) Cloud
Große Cloud-Anbieter, wie Microsoft, Google oder Amazon bieten Skalierungsmöglichkeiten, die man selbst nur schwer gewährleisten kann und wenn es denn sein muss, dann in einer Private-Cloud.

Aus all dem ergibt sich eine rasante…
…(7) Beschleunigung.

Alle 7 Aspekte bergen Chancen und Risiken. Natürlich ist es sinnvoll zu prüfen inwieweit sie für bestehende Geschäftsmodelle relevant sind und ob sich neue Türen öffnen. Diesen Fragen muss man sich aber immer stellen und nicht erst wenn irgendwelche Jünger ihre Digitalisierungssandalen in die Luft halten.

Und auch mit den Grenzen und Problemen der Digitalisierung müssen wir uns beschäftigen: Die Komplexität steigt und es entstehen neue Abhängigkeiten. Einem Kind würde man vorsichtshalber nicht seine Kreditkarte anvertrauen, dem Kühlschrank, den ein Wildfremder programmiert hat schon…

Lasst die Kirche im Dorf und macht eure Hausaufgaben, die ihr immer schon gemacht haben müsstet, dann ist Digitalisierung nur alter Wein in neuen Schläuchen. Zugegeben – vielleicht ist der Wein gereift, aber neu ist er wirklich nicht.

Beitrag #729 auf schlossBlog
Ein Vorgehensmodell zur Digitalisierung in KMUs gab es bereits in #693

Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.
 

Im Eifer des Gefechts meiner aktuellen Projekte wäre beinahe eine Buchveröffentlichung untergegangen:

Für den ersten Band „Beteiligungsprozesse erfolgreich planen“ der Reihe „Methodenhandbuch Bürgerbeteiligung“ durfte ich einen ausführlichen Artikel zur Stakeholderanalyse beitragen. Die Interpretation von Projekten (und ihrem Umfeld) als soziale Systeme lassen sich natürlich auch auf den öffentlichen Raum übertragen. Mit Konzepten wie der Stakeholderanalyse hat man dann ein Werkzeug, das auch in diesem Kontext genutzt werden kann. Die Stakehholderanalyse ist eine auf Interessen und Interessensgruppen fokussierte Form der Umweltanalyse.

Stakeholdermanagement, in: Hrsg.: Peter Patze-Diordiychuk, Jürgen Smettan, Paul Renner, Tanja Föhr, Methodenhandbuch Bürgerbeteiligung – Beteiligungsprozesse erfolgreich planen, München 2017 (Amazon)

Neben der #Projektaxt empfiehlt sich auch der sensible Einsatz der #Brechstange in der täglichen Projektarbeit. pic.twitter.com/WiqRux8xBS

— Bernhard Schloß (@schlossblog) 21. Mai 2017

Das Thema Fehler und Fehlerkultur hat mich jüngst über mehrere Wege eingeholt: Zum Einen bei der Erstellung unseres Qualitätsmanagementtrainings für die LinkedIn Learning Projektmanagement Reihe und zum Anderen über eine Diskussion ausgelöst durch einen Blogpost von Marcus Raitner gefolgt von einigen Repliken, u.a. von Stephan List auf dem Toolblog.

Was mir gar nicht gefällt ist die Verquickung der Begriffe Fehler und Scheitern. Während ein Fehler ganz neutral lediglich ein Ergebnis darstellt, das so weder erwartet noch gewollt war, birgt Scheitern eine stark persönlich wertende Konotation: Eine negative Wertung über die Leistungserbringung und den Leistungserbringer. Insofern würde ich gerne Marcus These („Scheitern erlauben – Fehler abschaffen“) etwas provokant auf den Kopf stellen:

Fehler erlauben – Scheitern abschaffen!

Ganz klar: Es geht nicht um unnötige und fahrlässige Fehler, aber es geht um Fehlerkultur. Es geht um einen konstruktiven Umgang mit Fehlern. Aktuelles Negativbeispiel ist wieder das Dieselgate und der desaströse Umgang damit in Politik und den betroffenen Firmen.

Aber was ist dann eine Fehlerkultur? Was macht eine (positive) Fehlerkultur aus?

(1) Akzeptanz von Fehlern
Fehler passieren. Ob wir wollen oder nicht. Dafür ist unsere Welt viel zu komplex, als dass wir alles kontrollieren könnten. Es ist sinnlos das zu negieren, vielmehr sollten wir den konstruktiven Umgang mit Fehlern suchen.

(2) Keine Schulddebatten
Beim konstruktiven Umgang mit Fehlern geht es nicht um die Schuldfrage, sondern um Lösungen. Es geht nicht um willfährigen, vorauseilenden Gehorsam, der nur auf das achtet, was vermeintlich erwartet wird, sondern um eine ehrliche und sachliche Auseinandersetzung.

(3) Transparenz
Wir brauchen selbstverständlich im Team Transparenz über unsere Fehler und Probleme. Das ist natürlich nur möglich, wenn niemand negative Konsequenzen aus seiner Ehrlichlkeit fürchten muss. Hier schließt sich der Kreis zur Schulddebatte. Es geht eben nicht um Fingerpointing auf Personen, sondern um Sachlichkeit.

(4) Fehlervermeidung kein Selbstzweck
Natürlich wollen wir keine unnötigen Fehler, aber Fehlervermeidung darf auch nicht zur Selbstzensur werden. Wir brauchen Handlungs- und Experimentierfreiräume um Lernen zu können und voran zu kommen. Das Negativbeispiel hier ist der Sprachenschüler, der seinen Mund nicht aufkriegt aus Angst einen Fehler zu machen und damit grandios an seinem Ziel – der Kommunikation – scheitert (upps, jetzt habe ich selbst von Scheitern gesprochen), statt mit Händen und Füßen zu kommunizieren und sein eigentliches Ziel zu erreichen. Die Fehlervermeidung an sich ist nicht das Ziel, sondern (in diesem Fall) die Kommunikation, aber das wird mitunter vergessen.

Wir brauchen also einen entspannteren Umgang mit Fehlern, aber keinen leichtfertigen, einen sachlichen und ganz bewussten.

Und auf die Energieverschwendung für Eitelkeiten und Schulddebatten können wir im Sinne des Teams gerne verzichten.

Christian hat über unserer Trainer-Tätigkeit für LinekedIn Learning/video2brain getweetet.

Und ich kann nur sagen: Mit Dir jederzeit wieder!

Trainer bei LinkedIn https://t.co/CgcmxdOm7f via @visualbraindump

— Bernhard Schloß (@schlossblog) May 6, 2017

Diese Tage kam ich in der Diskussion mit einem Kunden auf die Berücksichtigung von Security Requirements in einem agilen Kontext.

Hintergrund war, dass bislang Security vor allem für den Betrieb und für die Produktsicherheit thematisiert wird, aber Sicherheitsaspekte in der Entwicklung und in einer Projektphase noch eher stiefmütterlich behandelt werden. Auf der anderen Seite finden agile Vorgehensweisen immer weiter Einzug in die Unternehmen und die Ausgangsfrage des Kunden war, wie man Sicherheitsbelange im agilen Kontext berücksichtigen kann.

Für die Projektsicht gibt es vor allem zwei Themenstränge (und dabei müssen wir noch nicht mal zwischen agil und klassisch unterscheiden):

• Die Sicherheit im Projekt
• Die Entwicklung der Sicherheit für Produkt und Betrieb

Bei letzterem Punkt könnte ich mir unterschiedliche Strategien vorstellen:

• Ein stufenweiser Hochlauf, bei dem systematisch das Sicherheitsniveau angehoben wird. (Anfangs mit einer Sandbox, dann Aufbau einer Entwicklungsumgebung, erst noch ohne Daten, dann nur mit einem Teilset der Daten, bis hin zur vollumfänglichen Produktion)
• Vorgabe von Leitplanken (im Qualitätsmanagement gibt es dafür das Control Chart als Werkzeug).
• …

Grundsätzlich würde ich Security-Anforderungen im Normalfall den nicht-funktionalen Anforderungen zuordnen.

Agile SW-Entwicklung fokussiert tendenziell auf funktionalen Anforderungen. Werden dabei wichtige nicht-funktionale Anforderungen vergessen, so kann dies eine Schwäche agilen Vorgehens sein.

Im Wesentlichen finden sich drei Ansätze zur Berücksichtigung von Security Requirements im agilen Kontext:

• Eigene nicht-funktionale Einträge ins Backlog (beispielsweise eigene User Stories. Ein Kollege hat mir berichtete mir, dass er ein eigenes Backlog für Security Anforderungen aufgebaut hat.)
• Berücksichtigung nicht-funktionaler Anforderungen als Constraints
• Berücksichtigung als Kriterien im Definition of Done

Wenn die Vorgaben für Security oder nicht-funktionale Anforderungen allerdings zu sehr formalisiert werden, dann birgt das bereits einen kulturellen Konflikt: Ein formaler Prozess entspricht jetzt nicht ganz den agilen Vorstellungen von eigenverantwortlichem Handeln, d.h. auch da bräuchte es klar definierten Handlungsspielraum für das Team.

Maturity Ansätze fand ich zur Berücksichtigung von Security Anforderungen nicht hilfreich. Da finden sich  CMMI-Adaptionen auf agile Vorgehensweisen. Thematisiert wird aber das Vorgehensmodell an sich und nicht die Berücksichtigung nicht-funktionaler oder sicherheitsrelevanter Anforderungen.

Beitrag #723 auf schlossBlog

Mittlerweile sind die ersten 5 Trainings unseres Projektmanagement-Kurses online, ein weiters ist in der Post-Produktion und die Dreharbeiten für die nächsten Trainings stehen vor der Tür.

Die Video-Trainings sind sowohl bei video2brain als auch bei LinekdIn-Learning (kostenlos für LinkedIn-Premium-Abonnenten) verfügbar. Einzelne Demo-Filme aus dem Training kann man sich auch ohne Anmeldung ansehen (bei video2brain). Wer also neugierig geworden ist…

Die Entwicklung und Erstellung war sehr intensiv, hat aber auch wirklich Spaß gemacht.

Mit Christian, meinem Trainerpartner von visualbraindump, kann man Pferde stehlen, Thomas ist ein alter Hase was Lektorat und redaktionelle Betreuung angeht und bei der Grazer Crew von video2brain ist man in den allerbesten Händen.

Da kommt noch mehr – und ich freu mich darauf!

#Beitrag 722 auf schlossBlog

Diese Tage wurde ich zufällig Ohrenzeuge einer kleinen Gruppe von Agile Coaches in einem Großunternehmen.

Erst sprachen sie ihre Einführungsfolien durch („Da sollten wir noch auf die agilen Werte eingehen.“). Das Ganze from the scratch weil agiles Vorgehen #Neuland und so, aber groß im Kommen.

Dann war Mittag und ich durfte einem anderen Gespräch der agile Coaches folgen: „Bist du jetzt schon Senior oder noch Junior? Und wie sieht es mit deiner Zertifizierung aus?“

Klar solches Hierarchie- und Statusdenken ist voll agil.

Steht bestimmt auch im agilen Manifest… Zertifikate vor gesundem Menschenverstand.

Agiles Projektmanagement ohne ein entsprechendes Mindset ist vollkommen sinnlos.

Mit dem richtigen Mindset ist schon fast wieder die Vorgehensweise egal.

Jedes Projekt braucht Agilität. Aber die erreicht man nicht durch die Einführung von agilem Projektmanagement, sondern durch eine entsprechende Einstellung und entsprechende Verhaltenswesien. Aus diesen resultiert dann (vielleicht) wieder ein agiles Projektmanagement oder aber ein open-minded klassisches Vorgehen.

Sinnfrei eingeführtes agiles PM ist genauso bürokratischer Mist, wie jede andere ohne Verstand eingeführte Methode. Mag die Methode an sich noch so gut sein.

Beitrag #721 auf schlossBlog