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

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

Und hier kommt der zweite Film der PM-Reihe – https://t.co/JCjoplVh8x //Diesmal Solo für @schlossblog

— christian botta (@pottasson) 28. Februar 2017

Doris Helzle, Immer wieder einmalig – Erfolgreich in Projekten – pfiffig und kompakt, Saulheim 2016 (Amazon Affiliate Link)

Das kleine Büchlein von Doris Helzle ist eine humorvolle Projekt-Fibel mit wunderbaren Zeichnungen von André Poloczek (meine Favoriten sind das Reiten des toten Pferdes und der Sprung ins Neue/Unbekannte).

Doris Helzle weiß worauf es ankommt und deswegen stehen statt Methoden die Kommunikation und das Zwischenmenschliche im Vordergrund – da bin ich ganz bei ihr!

Sie hat wunderbare Bilder (nicht nur die von André Poloczek, sondern auch im übertragenen Sinne) für uns bereit: Seien es Lampe und Papierkorb mit ihren launigen Dialogen im Projektbüro oder das perfekte Verbrechen als Projektmetapher.

Einzig in einem Punkt tue ich mich schwer: Wem sollte ich diese Büchlein, das so schön gemacht ist, empfehlen?

Alten Projekthasen? Die würden Doris Helzle gleich zustimmen und am liebsten bei einem Bierchen mit der Autorin Projektanekdoten austauschen, aber etwas wirklich Neues würde ihnen nicht geboten.

Newbies? Da habe ich etwas Bedenken, denn sehr schnell geht die Autorin über elementare Begriffe hinweg und setzt das eine oder andere Mal vielleicht etwas mehr voraus, als man von dieser Zielgruppe erwarten darf. Klar weckt die Lektüre Appetit, aber für eine Einführung ist es dann doch etwas dünn.

Zyniker? Nein, dafür ist die Autorin zu pragmatisch.

Melancholiker? Vielleicht am Ehesten. So in den tiefen Abgründen eines Projekts, abends nach getaner Arbeit, um sich gemeinsam mit gleichgesinnten „auszukotzen“? Nun, dann vielleicht doch lieber auf ein Bierchen mit Doris Helzle…

Trotz allem, aber ein schön gemachtes Buch, das bei der Lektüre ein Schmunzeln ins Gesicht zaubert!

Beitrag #719 auf schlossBlog

https://t.co/QHRBTZSxIq der erste Kurs von @schlossblog und @pottasson ist jetzt auf @LinkedIn verfügbar #Projektmanagement

— Visual Braindump (@VisualBraindump) 9. Februar 2017

Ein Beitrag zur Blogparade des ProjektMagazin: „Klassisch, agil oder egal: Ist ein guter Projektleiter mit jeder Methode erfolgreich?“

Nun, diese Frage ist natürlich rhetorisch. Die meisten Teilnehmer an der Blogparade plädieren daher für das sowohl als auch, sprich:

Kompetenz des Projektleiters + Methodeneinsatz.

Gebhard Borck hebt das Zusammenspiel von Methodenkompetenz und Charakter hervor.

Tassilo Kubitz spricht etwa von sozialer Kompetenz und methodischem Vorgehen, dem möchte ich fast zustimmen, allerdings würde ich lieber von systematischen Vorgehen sprechen. Es gibt nicht EINE richtige Methode oder Vorgehensweise, sondern ein ganzes Spektrum. Der Begriff methodisches Vorgehen könnte dabei als Verengung auf eine Methode oder Vorgehensweise missverstanden werden.

Auch Alexander Blumenau weist darauf hin, dass man ohne Methodenwissen erfolgreich sein kann, dass Methoden aber dennoch wertvoll sind.

Stephan Witt betont, dass eine Methode zum Projekt und zum Team passen muss. Er greift dabei Tom Michls Forderung nach Geisteshaltung auf. Bestärkt wird dieser Fokus auf das Team auch durch Martin Dragosits: „Nicht Methoden entscheiden über den Projekterfolg, sondern Menschen.“

Eberhard Huber differenziert noch die Teambetrachtung und erinnert uns daran, dass nicht jede Gruppe, die ein Projekt bearbeitet auch ein Team ist.

Also gut – einigen wir uns auf ein sowohl als auch, aber warum?

Keine Methode der Welt kann sicherstellen, dass Sie das Richtige machen, aber Methoden können helfen, das was Sie machen richtig zu machen. Methodeneinsatz zielt auf Effizienz. Für den Projekterfolg braucht es aber vor allem auch Effektivität, daher wählt Stephan Witt ja auch als erstes Kriterium für die Methodenauswahl das Projekt oder den Projektgegenstand selbst.

Natürlich braucht es dann auch noch die Sozialkompetenz, um das Team (oder die Gruppe (oder die betroffenen Stakeholder)) mit dem Methodeneinsatz zu erreichen. Methoden sind kein Selbstzweck. Wir dürfen nicht blind ihrer eigenen Logik folgen. Für mich dienen Methoden vor allem der Facilitation. Methoden sollen befähigen. Sie sind vor allem ein Moderationswerkzeug und kein Patentrezept!

Gleiches gilt für Vorgehensweisen (klassisch, agil,…). Auch hier würde ich die gleichen Kriterien anwenden, wie Stephan Witt bei der Methodenauswahl. Ein Projekt bei dem das Vorgehen rein technisch strikt sequentiell vorgegeben ist und durch die äußeren Rahmenbedingungen auch eine Arbeitsteilung gefordert ist, kann man kaum in ein agiles Korsett zwingen. Auf der anderen Seite bringen agile Vorgehensweisen viele Rituale und Werkzeuge mit, die Kommunikation, Transparenz und Eigenverantwortung fördern, Dinge die jedem Projekt gut tun, aber das Team (die Gruppe (oder das Umfeld)) muss dafür auch bereit sein.

Beitrag #715 auf schlossBlog

Zur im vorletzten Beitrag vorgestellten Context Map gibt es jetzt auch ein eigenes Erklärvideo.

Die Downloads zum Template gibt es hier:

Context-Map DIN A4
Context-Map DIN A3
Context-Map DIN A2
Context-Map DIN A1
Context-Map DIN A0

Beitrag #714 auf schlossBlog