Jurgen Appelo writes a popular blog at www.noop.nl, that covers topics including Agile management, software engineering, business improvement, personal development, and complexity theory. He is the author of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders, which describes the role of the manager in Agile organizations. And he wrote the little book How to Change the World, which describes his new supermodel for change management. He is also a speaker who is regularly invited to talk at business seminars and conferences around the world.

Jurgen is co-founder of the Agile Lean Europe network (for Agile & Lean thinkers and practitioners in Europe) and the Stoos Network (focusing on change agents for organizational transformation).

Keynote Tag 1: "How to change the world"
Keynote Tag 2: " Blueprint for a tribal business!"

How to change the World!

“How do I make my managers more Agile?”
“How can I convince developers to educate themselves?”
“How can I make customers more cooperative?”
“How do I start a European network of Agile and Lean practitioners?”

When transforming organizations and other social systems people usually encounter obstacles. And these obstacles very often involve changing other people’s behaviors. Of course, we cannot really _make_ people behave in a different way. We also cannot really make people laugh, and we cannot really make people happy. But… we can certainly try!

This session is about Change Management 3.0. It is a new change management “super model” which views organizations as complex adaptive systems and social networks. The Change Management 3.0 supermodel wraps various existing models (PDCA, ADKAR, Adoption Curve and The 5 I's). It lists a few dozen hard questions that can help people in their attempts to change the behaviors of other people in an organization and beyond. No matter whether you are a manager, Scrum Master, Product Owner, software developer or writer, anyone will find it useful to know how to change the world around them.

Here you find Jurgen Appelos Leaflets to "How to change the world".

Blueprint for a tribal business!

Does a company really need a head office? The new organizational structure of the 21st century is the network, not the hierarchy. Workers in modern businesses need connections, not control. And the focus of management should be on leadership, not governance. But how can you organize this, in a way that is safe-to-fail?

Happy Melly is a company built from scratch as a network of multiple legal entities. They are connected through a shared Constitution, with regular Gatherings on Skype where they discuss collaboration, and with direct involvement of customers, freelancers, owners, and suppliers, who organize themselves in Huddles of stakeholders. The network is led and governed by a CEO and a Board, who can be voted out by the network at any time. The only way for them to stay on top is to keep everyone’s trust. Every day.

Here you find Jurgen Appelos Leaflets to "Blueprint for a tribal business"

Alistair Mavin (Mav) is a requirements specialist at Rolls-Royce PLC based in Derby, UK. Prior to joining Rolls-Royce he carried out systems engineering and requirements engineering projects in a range of industries including defence, aerospace, rail and automotive. He has experience in the development and delivery of requirements engineering training.

Mav has published many papers on requirements engineering and is a regular contributor to the IEEE “RE” conference series. He is a member of the “RE” conference series Industry Committee, a member of the British Computer Society’s Requirements Engineering Specialist Group Committee and is a chartered engineer.

Keynote Tag 2: Authoring Natural Language Requirements with the Easy Approach to Requirements Syntax Plus (EARS+) Notation

Black box system requirements are often written in unconstrained natural language, which is inherently imprecise. During system development, any problems in system requirements inevitably propagate to lower levels. This creates unnecessary volatility and risk, which impact programme schedule and cost. To mitigate this problem, there is a need to provide simple, practical guidance for authors of natural language requirements. Easy Approach to Requirements Syntax (EARS) is a philosophy for authoring natural language requirements through the application of a template with an underlying ruleset. EARS has proved popular with practitioners because it is lightweight, there is little training overhead, and the resultant requirements are easy to read.

In practice, requirements authoring is usually an iterative process; first-pass requirements can be quite a simple description of required system behaviour, whilst subsequent iterations are used to add detail. EARS is an effective mechanism for the expression of simple requirements, but does not adequately define precise, rigorous requirements. To address these shortcomings, the enhanced EARS+ template has been developed. EARS+ provides a mechanism to vary the level of detail in natural language requirements during iterative requirements authoring. The requirement author can add attributes such as stakeholder, action and object, which have defined syntax. This produces a precise description of the required system behaviour. The practitioner can choose which clauses to apply, thereby tailoring each requirement to the appropriate level of detail, whilst maintaining the readability of natural language.

This presentation will introduce the EARS+ template, illustrate with examples of both simple and detailed requirements and discuss the benefits of adopting the approach.

Trainer & Berater, OberSOPHISTin (formal: Gründerin und geschäftsführende Gesellschafterin), Chefberaterin, Coach und Trainerin. In 20 Jahren Berufstätigkeit sammelt sich so einiges an ... ein Unternehmen ...6 Bücher ...40 Mitarbeiter ...ungezählte Artikel und Vorträge... und unheimlich viel Erfahrung. Meine Leidenschaft für die Projektberatung ist vermutlich Schuld daran, dass ich bis heute nicht „nur“ manage, verwalte und Menschen fördere, sondern auch ganz nah am Kunden dran bin, in Projekten maßgeblich mitarbeite. Vielleicht aber auch das Talent, die richtigen Mitarbeiter um mich zu scharen. Gute Ideen so umzusetzen, dass Entwickler, Vertragspartner, direkt und indirekt betroffene Anwender das Gefühl haben, ein intelligentes, durchdachtes und nutzbringendes Produkt vor sich zu haben, ist die Vision die mich dabei antreibt.

Vortrag - Tag 2: Agiles Requirements Engineering – Requirements Engineering in agilen Projekten

Vermeiden Sie die Spätfolgen einer Fehlinterpretation der agilen Werte

In den vergangenen Jahren hat die Agilität zunehmend Einzug in die Softwareentwicklung gehalten. Dies reicht vom Leben der agilen Werte, über die Anwendung der Prinzipien, bis hin zum Einsatz agiler Prozesse wie beispielsweise Scrum. Der Fokus auf die Wünsche des Kunden und auf die Fähigkeiten der Entwickler sind nur zwei fundamentale Prinzipien, die den Erfolg der agilen Softwareentwicklung ausmachen. Agile Vorgehensweisen erzeugen in regelmäßigen Abständen auslieferbare Inkremente, wodurch der Kunde früh in die Produktentwicklung eingebunden werden kann.

So erfreulich und positiv das alles klingt, das agile Vorgehen hat bei falscher Anwendung auch seine Schattenseiten. Der Fokus auf das auszulieferende Produkt führt zur Vernachlässigung der Dokumentation. Während der Entwicklung sind alle Beteiligten nahe beieinander und das Wissen ist präsent. Nach der Fertigstellung des Produkts werden die Beteiligten allerdings auf neue Projekte verteilt oder verlassen im schlechtesten Fall sogar das Unternehmen. Für die Wartung oder Weiterentwicklung des Produkts fehlt dann Wissen. Auf das noch vorhandene Wissen lässt sich zudem aufgrund der begrenzten zeitlichen Ressourcen im Alltagsgeschäft bzw. des schwindenden Erinnerungsvermögens der Beteiligten nur schwierig zugreifen.

Eine Lösung für dieses Problem ist die Dokumentation des Produkts entweder nach dessen Fertigstellung (Nachdokumentation) oder eine agile Dokumentation bereits während der Erstellung. Bei der Nachdokumentation ergeben sich allerdings einige Unterschiede zur Dokumentation, die während einer Entwicklung erstellt wird. Der Vortrag erläutert diese Unterschiede, beschreibt welche Informationen überhaupt relevant sind und wie ausführlich Sie diese dokumentieren sollten.

Bei der Dokumentation während der Erstellung eines Systems mit agilem Vorgehen sind ebenfalls Rahmenbedingungen zu beachten, die Ihnen der Vortrag aufbereitet.

Ziel des Vortrags ist es Ihnen eine Empfehlung minimaler Dokumentationselemente zu geben, die Sie für neue oder bereits laufende agile Projekte verwenden können. Dadurch können Sie abhängig vom Projektfortschritt den Aufwand und die Kosten für eine Dokumentation oder Nachdokumentation reduzieren oder sogar vermeiden.

Dipl.-Ing. Jörg Hermes arbeitet seit dem Abschluss seines Studiums der Elektrotechnik im Jahr 2001 in der Entwicklung von sicherheitsrelevanten Systemen in verschiedenen Funktionen entlang des V-Prozesses. Als Mitglied der Gesellschaft für Informatik pflegt er den Austausch zwischen Wissenschaft und Industrie mit den Schwerpunkten Softwareverifikation und -validierung sowie Anforderungsmanagement.
Nach umfangreichen Erfahrung im Bereich der Entwicklung komplexer Medizinprodukte ist Jörg Hermes seit 2005 in der Automotive-Branche tätig. Dort arbeitete er an den Themen Softwaretest, Systemengineering und leitete fachlich eine interdisziplinäre Funktionale Sicherheitsgruppe. Er beschäftigte sich ausgiebig mit der Einführung der ISO 26262. Jörg Hermes führt seit Anfang 2011 Trainings der ISO 26262 Norm durch und arbeitete inhaltlich und prozessdefinierend in verschiedenen Rollen entsprechend der Funktionalen Sicherheits-Norm bei Automobilzulieferern.

Vortrag Tag 1: Die Wichtigkeit des Anforderungsmanagement im Kontext der ISO 26262

Die Forderungen an das Anforderungsmanagement finden sich in der ISO 26262 an vielen Stellen über alle Kapitel verteilt, so dass inhaltliche und organisatorische Aspekte zu berücksichtigen sind. Eine zusätzliche organisatorische Herausforderung an das ISO 26262-konforme Anforderungsmanagement liegt in der Aufgabenteilung zwischen OEM und Tier1 sowie Tier1 und Tier2, da genaue Absprachen getroffen werden müssen. Desweiteren müssen Anforderungen welche Funktionsverteilungen über Steuergeräte erstellt und abgestimmt werden.
Bei meinen Kunden konnte ich beobachten, dass die Ableitung von Anforderungen zur Funktionalen Sicherheit schwierig ist, da in den FuSi-Fachabteilungen das Wissen über Anforderungsmanagement nur in geringem Umfang vorhanden ist oder fehlt. Außerdem werden nur selten Hardware-Anforderungen zur Funktionalen Sicherheit aufgestellt, die Tendenz dazu ist jedoch steigend.
In meinem Vortrag möchte ich die normativen Bezüge zum Anforderungsmanagement darstellen und die Herausforderung bei der verteilten Entwicklung erläutern. Als weiteren Punkt möchte ich die Unterschiede zwischen der Verfeinerung und der Ableitung von Sicherheitsanforderungen erklären und schließlich einen Ansatz vorstellen, der sich hervorragend zur Formulierung von Anforderungen eignet und die Berechnung normativ relevanter Hardware-Metriken unterstützt.

Dr. Stefan Walburg ist als Prozessmanager bei Siemens Healthcare verantwortlich für die Definition von Softwareentwicklungs- prozessen für medizinische Produkte im Bereich bildgebender Verfahren. Nach seinem Studium der Wirtschaftsinformatik promovierte er am Wissenschaftlichen Institut für Hochschulsoftware und arbeitete danach als Berater mit den Schwerpunkten Anforderungs- und Systemanalyse. Zuletzt war er als Projektleiter für die Entwicklung und Einführung eines standardisierten
Softwareentwicklungsprozesses für einen großen IT-Dienstleister im PublicSector tätig.

Vortrag Tag 1: Integrierte Softwareentwicklung am Beispiel eines Medizinprodukts

Die Entwicklung von Software für Medizinprodukte befindet sich im Spannungsfeld zwischen stringenten regulatorischen Anforderungen, ambitionierten Time-to-Market- und Budgetvorgaben, großer systemischer Komplexität sowie höchsten Qualitätsanforderungen.

Der Vortrag zeigt einen Entwicklungsprozess, der „konservative Werte“ mit agilen Methoden paart und mittels eines integrierten ALM-Ansatzes (Application Lifecycle Management) – von der Projektplanung bis zur Systemvalidierung – Transparenz über alle Entwicklungsphasen schafft.
Das zugrunde liegende iterative Vorgehensmodell verlangt eine frühzeitige und kontinuierliche Involvierung der relevanten Stakeholder und fordert über verbindliche Quality Gates in jedem Sprint ein hohes Mindestmaß an Entwicklungsqualität (inklusive Dokumentation). 

Der Vortrag geht insbesondere auf Lebenszyklen und Beziehungen von Anforderungen und Testfällen ein und zeigt, wie deren geeignete Kopplung zu mehr Entwicklungseffizienz beiträgt.

Nach seinem Studium der Nachrichtentechnik an der Berufsakademie Stuttgart arbeitete Reiner Beckmann seit 1997 bei EADS in den Bereichen Militärflugzeuge und  Eurocopter.
Seit 2010 ist er Leiter der Organisation „Specifications & Testing“ im Systemunterstützungszentrum NH90/Tiger bei Eurocopter und dort für die Betreuung von Anforderungen und Softwaretest von 14 Avionikrechnern der beiden Hubschrauber NH90 und Tiger verantwortlich.

Vortrag Tag 2: Einführung der UML in den Geschäftsbereich

Tiger und NH90 sind multinationale, militärische Hubschrauber, deren Entwicklung bereits in den 80-er Jahren des vorigen Jahrhunderts begonnen wurde.

Da für militärische Entwicklungsvorhaben strenge Anforderungen an verwendete Prozesse, Standards und Tools gestellt werden, sind viele der eingesetzten Techniken noch Relikte aus der Frühzeit des Software Engineering. Was damals modern war, ist heute nicht falsch. Allerdings wird es zunehmend schwieriger, Support für die notwendigen Tools und IT-Umgebungen zu finden und neuen, jungen Mitarbeiter attraktive Entwicklungsmöglichkeiten zu bieten.

Technische Innovationen sind allerdings im starr reglementierten, militärischen Umfeld sehr aufwändig in der Einführung. Ebenso kann die Unmenge an bereits vorhandenen Informationen nicht ohne weiteres in neue Umgebungen portiert werden.

Der Vortrag „Einführung von UML in den Geschäftsbereich“ stellt dar, warum UML eingeführt wird, welche Voraussetzungen gegeben sind und mit welchen Mitteln die existierenden Herausforderungen zu meistern versucht werden.

Leiter des Bereiches Elektrik/Elektronik Telematik der Daimler AG

Dipl. Ing. Peter Häußermann, geboren 1955  in Backnang, studierte Elektrotechnik mit der Fachrichtung theoretische Nachrichtentechnik an der TU Stuttgart. 1979 Eintritt in die Daimler AG, ab 1986 in leitender Position.
Seit 1996 verantwortlich für die Entwicklung der Multimedia-, Navigations- und Kommunikationssysteme sowie für Bedien- und Anzeigekonzepte aller Mercedes-Benz PKW-Baureihen.

Vortrag Tag 2: RE-Herausforderungen im Infotainment eines automotive OEM's

Der Infotainment-Bereich im automobilen Umfeld muss sich immer wieder großen Herausforderungen durch fundamentale Veränderungen im Umfeld stellen. Diese reichen aktuell vom "Connected Car" über die Integration von Fahrassistenzsystemen in die Infotainment-Welt bis hin zu grundsätzlichen Fragestellungen, wie weit ein OEM in der Festlegung von Systemen geht. Dabei bewegt sich der Infotainment-Bereich aus Sicht des Requirement Engineering alles andere als in "ruhigem Fahrwasser"! Zu viele Spezifikationen erschweren den Überblick über die Systeme und die Spezifikationserstellung braucht - wie immer - zu lang.
Der Vortrag zeigt aus Sicht des Managements, kommend von einer Analyse des Ist-Standes, wie im Infotainment-Bereich bei der Daimler AG die vielfältigen Themen aufgegriffen werden und welcher Weg zu deren Lösung geplant ist.

Dr. Matthias Recknagel leitet das Team "Requirements Management" in der Vorentwicklung Daimler AG in Sindelfingen. Zu seinen Aufgaben gehört es, Methoden und Prozesse des Anforderungsmangements für die Anwendung in der Fahrzeugentwicklung bereichsübergreifend weiterzuentwickeln und zu harmonisieren. Eine wichtige Rolle spielen dabei die Unterstützung der Methoden durch geeignete Tools sowie der Austausch und die Abstimmung von Spezifikationen mit Entwicklungspartnern.
Erfahrungen aus der Einführung von RM-Methoden in der Telematik-Entwicklung der Daimler AG sowie aus der langjährigen Entwicklung von automatisierten Mess- und Prüfsystemen für den Einsatz in der Fertigung erleichtern das Verständnis für Bedürfnisse von Entwicklern und Lieferanten.

Dr. Stefan Queins ist Trainer und Berater bei SOPHIST.
Ich habe nach dem Studium der Informatik in meiner Promotion untersucht, wie sich das Anwendungsfeld einer Problemstellung bei der Anpassung eines Entwicklungsprozesses ausnutzen lässt. Als Berater verwende ich objektorientierte Methoden und Notationen in den Bereichen der Systemanalyse und Architektur von technisch orientierten Systemen. Zusätzlich helfe ich auch bei der Einführung von angepassten Vorgehensmodellen in Entwicklungsprojekten. Auch im Trainingsbereich vermittle ich in den genannten Bereichen mein Wissen. Mein Interesse an der praxisnahen Forschung habe ich auch nach meiner Promotion nicht verloren und setze die dort entwickelten Ergebnisse gewinnbringend in meinen Projekten ein.

Vortrag Tag 1: Hardware-Anforderungen...so oder so

Der Begriff der Hardware-Anforderungen wird in vielen Projekten häufig nur in einer Richtung interpretiert: Welche Voraussetzungen gelten für das zu entwickelnde System und welche Randbedingungen resultieren daraus für die Entwicklung? Viel spannender scheint aber die Frage, wie z.B. die Umgebung eines eingebetteten Systems dessen Funktionalität beeinflusst. Oder ist es vielleicht geschickter, das gestellte Problem durch neue Anforderungen an ein Nachbarsystem zu lösen, das auch Einfluss auf die betrachteten Größen hat.

In diesem Vortrag werden wir die Zusammenhänge zwischen diesen Fragestellungen an einem Beispiel aus der Fahrzeugentwicklung transparent machen. Wir zeigen Ihnen einen durchgängigen Weg von der Problemstellung bis hin zu den Anforderungen an verschiedene beteiligte Systeme. Dabei werden wir deren physikalische Zusammenhänge betrachten, um nachvollziehbar qualitativ hochwertige Anforderungen zu ermitteln. Als Beispiel dient uns dabei ein System aus der Hybrid-Motorenentwicklung bei der Daimler AG.

More than 17 years experience as a project engineer and manager dealing with demanding projects in building technology in the automotive and pharmaceutical industries.
More than 50 international design reviews and audits in Europe, Asia and South America within the last 10 years.
Subject Matter Expert (SME) for Power Supply and HVAC Control for Roche Global Engineering.
Coordinator for the Electrical Power Supply of the Roche Site Mannheim

Vortrag Tag 1: RE in der Gebäudeplanung – ein Erfahrungsbericht

Gebäude sind allgegenwärtig. Es gibt Große und Kleine, Hübsche und weniger Hübsche. Manche Gebäude werden zum Wohnen genutzt, andere wiederum zum arbeiten. Was alle Gebäude gemein haben, ist dass sie einmal gebaut für mehrere Jahre an Ort und Stelle bestehen bleiben und nur mit großem Aufwand abgeändert werden können. Das führt zu speziellen Ansprüchen bei der Entwicklung solcher Gebäude, denn man muss schon sehr genau wissen, was man bauen möchte, bevor das Gebäude gebaut wird. Folglich braucht man Requirements Engineering. Aber…
Requirements Engineering ist in der Softwareentwicklung zur Klärung der Anforderungen bekannt und kann auf eine starke Verbreitung blicken. Beim Gebäudebau ist bis dato Requirements Engineering eher unüblich. Zumindest wird nicht das Requirements Engineering betrieben was aus der Softwareentwicklung bekannt ist, oder vielleicht wird es nur nicht so genannt. Was man ziemlich schnell erkennt, ist das es gravierende Unterschiede in der Vorgehensweise bei der Planung eines Gebäudes zur Vorgehensweise in der Softwareentwicklung gibt. Allerdings entstehen auch bei einem Gebäudeplanungsprojekt Probleme, die manchmal sehr speziell aber manchmal auch „alte Bekannte“ sind.
Dieser Vortrag zeigt, wie Requirements Engineering Methoden die aus der Softwareentwicklung bekannt sind in der Gebäudeplanung eingesetzt wurden und welche Vorteile sich daraus für das Projekt ergeben haben und welche Vorteile für die zukünftigen Projekte erwartet werden.

Trainer und Berater SOPHIST
Ich bin für die SOPHISTen als System Engineer unterwegs und unterstütze unsere Kunden von der Anforderungsanalyse über das Systemdesign bis hin zum Softwaredesign. Dabei verwende ich sowohl die textuelle als auch die modellbasierte Dokumentation von Anforderungen und setze objektorientierte Methoden zur Analyse und zum Design von Systemen ein. Als Trainer führe ich unsere Kunden in die Bereiche Requirements Engineering ein und bereite sie auf die Prüfung zum CPRE-Foundation Level vor. und Nach meinem Informatikstudium habe ich zusammen mit SOPHIST an dem Thema Validierung von Systemarchitekten auf Basis der UML gearbeitet und diese Ergebnisse in meine Promotion einfließen lassen.
Privat bin ich in einer geselligen Runde, beim Sport und in unmittelbarer Nähe von Büchern und Musik zu finden. Ich beschäftige mich zudem mit der modelgetriebenen Softwareentwicklung und wende sie im Bereich Java EE auch in verschiedenen Projekten an.

Vortrag Tag 2:

MASTeR of the Requirements Universe
Mustergültige Anforderungen – die SOPHIST Templates für Requirements

Die SOPHIST-Satzschablone für funktionale Anforderungen wurde und wird in vielen Projekten als Hilfsmittel zur Dokumentation natürlichsprachlicher Anforderungen verwendet. An einigen Stellen stößt sie allerdings an ihre Grenzen. Wir haben dies als Herausforderung gesehen und an der Erweiterung der Grenzen gearbeitet. Das Ergebnis ist eine ganze Schablonenfamilie, mit der nun sowohl funktionale als auch nicht-funktionale Anforderungen (NFA) dokumentiert werden können. Unsere funktionale Schablone haben wir etwas aufpoliert und mit einigen Erweiterungen für detaillierte Anforderungen versehen. Ganz neu sind mehrere Schablonen, um nicht-funktionale Anforderungen sowie Bedingungen natürlichsprachlich zu beschreiben.
Die Bestandteile der einzelnen Schablonen für unterschiedliche Arten von Anforderungen zeigen, welche Inhalte in guten Anforderungen nicht vergessen werden sollten. Anleitungen liefern die notwendigen Informationen, um im Alltag schnell zur korrekten Anwendung zu finden.

Harald Kretz arbeitet als Trainer in den Themenfeldern Visualisierungstechniken, Präsentation, Kommunikation, Führung und Selbstmanagement. Er ist Ingenieur und NLP-Trainer (DVNLP). Noch ein Hinweis zu Risiken und Nebenwirkungen. Schon einige SOPHIST Mitarbeiter/innen wurden nach einem Training bei Harald vom einem "Visualisierungsvirus" erfasst.

Workshop Tag 1: Visualisierungsworkshop

Kreative Visualisierungstechniken - Bildsprache und visuelle Begleitung von Prozessen
Denk-, Dialog- und Planungsprozesse funktionieren mit Bildern und der Bildsprache besser als rein verbale Interaktion oder Texte. Wir können unser Gehirn noch effektiver nutzen, wenn wir die für analytisches Denken und bildliches Vorstellungsvermögen ausgelegten Gehirnareale nutzen. Paart man Begriffe und Zahlen mit Bildern, entstehen einfach Sinnzusammenhänge und Assoziationen, die eingängig und merkbar sind. Dialog- und Planungsprozesse in Gruppen werden erleichtert, wenn die Prozesse grafisch verfolgt werden können. Zusammenhänge zu sehen und sich über deren Bedeutungen zu verständigen, macht die Sache leichter. Visualisierungen helfen Erkenntnisse zu sichern, Aussagen auf den Punkt zu bringen und Vereinbarungen herauszuarbeiten.

Pecha Kucha Vorträge der SOPHISTen