Schlagwortarchiv für: Agile

Klassische oder agile Verträge: So finden Sie die passende Vertragsart

Klassische Projekte und deren Verträge haben eine entscheidende Schwäche. Obwohl sie ein großes Maß an (vermeintlicher) Budget-Sicherheit bieten, können sie bei der Geschwindigkeit der schnelllebigen Unternehmenswelt kaum noch mithalten.

So wird aus der Sicherheit, genau zu wissen, wann ein Produkt fertig ist und welche Funktionen es umfasst, die Gefahr, ein veraltetes Produkt zu erhalten, das nicht mehr den aktuellen Anforderungen entspricht.

Gerade bei komplexen Softwareproblemen stoßen Sie mit klassischen Verträgen schnell an die Grenze. Denn in der modernen Softwareentwicklung wird zunehmend agil entwickelt. Das bedeutet: Weder das Produkt, das geliefert wird, noch wann das Produkt fertig wird, stehen zu Beginn der Zusammenarbeit eindeutig fest. Vertraglich lässt sich dies nur über Verträge abdecken, die eine agile Zusammenarbeit ermöglichen.

In diesem Artikel erfahren Sie, was genau „agile Verträge“ ausmacht und ob sie auch für Ihr Projekt geeignet sind.

Fünf entscheidende Unterschiede von klassischen und agilen Verträgen

Zunächst einmal schauen wir uns an, wie sich klassische und agile Verträge unterscheiden. Ich habe die wichtigsten Unterschiede in einem kurzen Video auf den Punkt gebracht:

Es lässt sich festhalten, dass sich die beiden Vertragsarten vor allem in fünf grundlegenden Punkten unterscheiden:

  1. Projektumfang: Bei einem klassischen Werkvertrag ist der Projektumfang meistens auf einen langen Zeitraum festgelegt. Das bedeutet, alle Anforderungen werden in einem Pflichtenheft gesammelt und anschließend abgearbeitet. Nicht so bei einem agilen Vertrag. Hier können Änderungen nach jedem Sprint vorgenommen werden. Dadurch kann das Entwicklerteam Feedback zeitnah berücksichtigen. Die Basis ist jedoch auch hier ein Backlog, bei dem der Aufwand zu Beginn geschätzt wird.
  2. Projektzeitraum: Der Zeitpunkt der Releases und Milestones ist bei klassischen Verträgen festgelegt. Bei agilen Verträgen gilt: Das Projekt ist beendet, sobald das Produkt fertig ist. Natürlich können Sie auch einen Zeitraum bzw. eine fixe Anzahl an Sprints festlegen. Ergebnisse, die zu diesem Zeitpunkt bereits vorhanden sind, können Sie übernehmen.
  3. Release-Zyklen: Die Release-Zyklen bei klassischen Projekten betragen mehrere Monate bis Jahre. Bei agilen Verträgen gibt es im Idealfall nach jedem Zyklus (Sprint) einen Prototypen, der getestet werden kann.
  4. Budget: Das Budget kann bei beiden Vertragsmodellen sowohl nach T&M (Time & Material, oder auf deutsch Vertrag auf Zeit und Materialbasis) abgerechnet werden oder auch fixiert werden. Im agilen Fall heißt das, dass eine bestimmte „Run-Rate“ des Teams budgetiert wird.
  5. Steuerung: Hier gilt Output vs. Outcome. Bei klassischen Verträgen wird zum Beispiel gemessen, ob das Entwicklerteam zum Zeitpunkt X den entsprechenden Milestone erreicht hat. Bei agilen Verträgen wird geprüft, ob das Produkt die Anforderungen der Kunden erfüllt.

Zusammenfassend lässt sich festhalten, dass bei klassischen Verträgen ganz klar die Budget-Sicherheit im Vordergrund steht. Agile Verträge geben dem Entwicklerteam deutlich größere Freiheiten, auf kurzfristige Änderungen zu reagieren und regelmäßig Feedback zu sammeln, um schlussendlich das beste Produkt für Kunden zu entwickeln.

So finden Sie die passende Vertragsart

Ob agile oder klassische Verträge die bessere Wahl sind, hängt von zwei grundlegenden Faktoren ab: der Projektkomplexität und der Arbeitsweise in Ihrem Unternehmen.

Komplexe Projekte brauchen agile Verträge

Agile Verträge sind nicht für jedes Projekt die richtige Wahl. Es ist entscheidend, dass Sie sich im Vorfeld Gedanken machen, welche Aufgaben im Projekt anfallen und wie gut Sie sie definieren können. Hierbei können Ihnen folgende Fragen helfen:

  • Sind Sie sich sicher, dass sich die Rahmenbedingungen während des Projekts nicht ändern werden? 
  • Sind Sie sicher, dass sich der Wert für Ihr Unternehmen genauso erreichen lässt, wie Sie es definiert haben?
  • Bestehen die Aufgaben ausschließlich aus wiederkehrenden Tätigkeiten?
  • Sind die Risiken der technischen Implementierung gering bzw. sind die Anforderungen klar formulierbar? 
  • Ist das Projekt eher klein und nicht langfristig angelegt, sodass Sie kein Team für die Betreuung und Weiterentwicklung des Produkts benötigen?
  • Kaufen Sie ein standardisiertes Produkt, dass keine Integration in ein bestehendes Produkt benötigt? 

Wenn Sie alle Fragen mit „Ja“ beantworten können, ist vermutlich ein klassischer Vertrag ausreichend. Ihr Projekt und die Anforderungen lassen sich im Vorfeld bereits genau definieren. Anders sieht es aus, wenn Sie nur einige der Fragen mit „Ja“ beantworten können. In diesem Fall ist es lohnenswert, sich das Thema agile Verträge genauer anzuschauen.

Keine agilen Verträge ohne agile Arbeitsweise

Die Komplexität Ihres Projekts ist allerdings nicht der einzige entscheidende Faktor. Wenn Sie in Ihrem Unternehmen nicht in der Lage sind, agile Projekte umzusetzen, bringt Sie auch ein agiler Vertrag nicht weiter.

Denn um das bestmögliche Produkt agil zu entwickeln, muss bei einer Anbieter-Kunden-Beziehung eine Kultur herrschen, die eine enge Zusammenarbeit und Anpassungsfähigkeit ermöglicht. Die Grundlage bilden hierbei die Prinzipien des agilen Manifestos. Ursprünglich stammt das Manifesto aus der Softwareentwicklung. Es lässt sich jedoch auch auf Unternehmen übertragen. 

Überlegen Sie sich, ob Sie in Ihrem Unternehmen eine Basis für agile Projekte besitzen und folgende Punkte gewährleisten können:

  • Feedback-Zyklen: Sie sind in der Lage, schnelle Feedback-Zyklen (idealerweise alle 2 bis 4 Wochen) umzusetzen und dem Entwicklerteam kontinuierliches Feedback zu geben.
  • Transparenz: Sie können während des Projekts vollständige Transparenz gewährleisten. Das bedeutet das Entwicklerteam hat einen Zugang zum Backlog, dem Fortschritt der Implementierung unterschiedlicher Features und den Ergebnissen nach jedem Feedback-Zyklus.
  • Variabler Projektumfang: Sie sind damit einverstanden, dass das Feedback nach jedem Zyklus mit in die weitere Produktentwicklung einfließt. Projektumfang und Aufgaben können entsprechend angepasst werden. Die Option muss auch vertraglich festgehalten werden, zum Beispiel über eine „Changes for free“ Klausel. Sie ermöglicht Änderungen im Backlog, sofern sie keinen Mehraufwand bedeuten.
  • Effektive Zusammenarbeit: Sie können eine enge Zusammenarbeit zwischen sich, dem Entwicklerteam und dem Endkunden gewährleisten. Idealerweise arbeitet das Team an einem Ort, sodass eine direkte und informelle Kommunikation möglich ist. Wenn der Anbieter eine Person vor Ort stellt, die eine aktive Rolle im Projekt übernimmt (keine Managementrolle, die nur als Verbindung zum Entwicklerteam dient) ist dies von Vorteil.

Wenn Sie die folgenden Punkten umsetzen können und außerdem komplexe Projekte haben, sind agile Verträge vermutlich eine gute Wahl. Sollten Sie noch kein agiles Mindset in Ihrem Unternehmen etabliert haben und dennoch mit agilen Projekten arbeiten wollen, können Sie sich mit Workshops diesem Ziel nach und nach annähern. Schreiben Sie uns gerne, wenn Sie weitere Informationen benötigen. 

Wann ist eine agile Arbeitsweise sinnvoll?

Kein Projekt ist wie das andere. Und kein Unternehmen gleicht dem anderen. Daher können für die Zusammenarbeit mit Ihren Kunden und Partnern nicht immer die gleichen starren Rahmenbedingungen gelten.

Überlegen Sie sich im Voraus, welche Rahmenbedingungen Sie für das jeweilige Projekt benötigen und ob Ihr Unternehmen eine agile Arbeitsweise lebt. Vor allem, wenn Sie komplexe Projekte umsetzen wollen, bieten eine agile Arbeitsweise bzw. agile Verträge eine solide Grundlage.

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

Unsere Trainings: Natürlich auch Remote!

Genau wie alle anderen Teile der TechTalk musste auch der Trainingsbereich, dessen Herz natürlich die erst kürzlich neu geschaffenen DC Spaces sind, auf die neue Situation reagieren.

Daher stellen wir unser Trainingsangebot auf Remote-Kurse um, bei denen Sie mit unseren internationalen Speakern virtuell interagieren können. Da wir bei TechTalk sowie unsere Trainer langjährige Erfahrung mit Remote-Arbeit haben, können wir auf dieses Wissen bei der Organisation von unseren neuen Kursformaten zurückgreifen.

Die ersten Trainings, die wir vollständig remote durchführen, sind:

Agile at Scale, Inspired by Spotify

mit Joakim Sunden, 19-22 April 2021

Automated Acceptance Testing and Story- Driven Development

mit Dave Farley, 23.-24 September 2021

Weitere Remote-Kurse und kostenfreie Meetups/Workshops werden wir in Kürze bekanntgeben. Folgen Sie uns auf LinkedIn oder Twitter, um die Ankündigung nicht zu verpassen.

Breakfast Event: Agile Contracts

Komplexe Vorhaben benötigen rasche Feedbackzyklen und iterativ inkrementelles Vorgehen. Doch wie sehen Vertragsmodelle dazu aus?

Wir laden Sie zu einem Vortrag und anschließendem Erfahrungsaustausch mit der agilen Community ein.
Richard Brenner, Agile Coach bei TechTalk, erklärt wie „Agile Contracts“ aufgesetzt werden und worauf dabei besonders zu achten ist.

  • Wie können wir ein Modell finden, das sowohl Risk Sharing ermöglicht als auch die Prozesse mit Legal und Procurement nicht erheblich verkompliziert?
  • Wir wollen Verträge haben, die im Streitfall eine klare Regelung ermöglichen. Oftmals passen die klassischen Fixpreise nicht und auch T&M scheitert, weil der Auftraggeber dadurch zu wenig Verantwortung beim Vendor sieht.

TechTalk stellt in diesem kompakten Breakfast-Event ein sehr konkretes Verrechnungsmodell vor, das sowohl Risk Sharing beinhaltet als auch einfach in der Abwicklung ist. Wir haben dieses Modell derzeit im Einsatz und geben diese Erfahrung weiter.


Thema des nächsten Agile Breakfast ist:

„Mut zur Innovation in regulierten Branchen“

Details zur Veranstaltung:

24.03.2020, von 08:30 bis 09:30 Uhr
Saturn Tower, 16. Stock
Leonard-Bernstein-Strasse 10, 1220 Wien 

Anmeldung

Ja, ich komme sehr gerne!

Wir würden uns freuen, Sie begrüßen zu dürfen.

PS: Sollten Sie verhindert sein, informieren wir Sie gerne über künftige Ausgaben unserer Agile Events.

… bitte laden Sie mich zur nächsten Agile Veransaltung ein und senden mir die Unterlagen zu Agile Contracts nach dem Event zu!

Agile Teams: A Method to Enable Autonomy by Clarity of Roles

How can you enable teams to take initiative and autonomy by knowing their decision boundaries? In this blog post, I am sharing the concept for a workshop format that you can adapt to achieve that goal.

I used this method to address the following situation: within a classical organization, new cross-functional teams are put together and are now supposed to work in an agile way, but they are stuck at the beginning because they do not know what they are allowed to decide. In addition, the concept of shared responsibility in these new teams is new. A second effect is also that those teams are not stuck, but they are now willing to take initiative, decide certain things (like for example an architecture decision), but then their manager is not happy with the decision and overrules. Also leading to a stuck team.

The problem is that there are unspoken assumptions about what autonomy means between managers and the teams or other stakeholders around the team. We want to reveal those assumptions!

This blog post is based on the talks at the agile tour 2019 and at the ASQF agile night.

Important preconditions in the mindset

A basic precondition is that the organization and all the stakeholders understand the concept of small autonomous teams or the “law of the small team” as Denning describes it (Denning, 2018). Those teams act aligned with the product and corporate vision and are be able to self-direct and self-manage to achieve the goals.

Leaders and managers understand that they should enable those teams by following the concept: “Push authority to information”, one of the major principles of intent-based leadership because we know that they are the experts in their domain and can make the best decisions.

Source: Intent-Based Leadership Keynote by Jenni Jepsen @Agile Tour Vienna“

In order to that, we need to give control to the teams, which is a gradual shift, not a one-off “now you do it all” because we need to check if the competence in the team is there.

Source: Intent-Based Leadership Keynote by Jenni Jepsen @Agile Tour Vienna“

Third, it is clear that we can only manage the environment and not the people.

Workshop Format

The goal of the workshop format is to reveal who is ultimately deciding and how much of these decisions can be delegated to the team. This question can arise between for example the former line manager, the department lead, a software architect or other stakeholders.

Step 1: Key Decision Areas

First of all, we need to collect the most important decision areas where we faced problems or need clarity. It is important that you do not list all decision areas as this would end up in a huge probably Excel sheet that nobody uses later anymore.

Key decision areas can be for example:

  • Who is responsible for deciding on vacations?
  • Who can decide it is a good thing to go on home office or not?
  • Who decides ultimately about an architectural proposal?
  • Who decides how much a solution proposal can cost?
  •  Can we invest as a team in experimenting with solutions for a given problem?
  •  Can we decide on hiring external consultants?
  • Who is responsible for staffing the team?

Step 2: The RACI matrix

You can skip this step if you only need to clarify the delegation between one role and the team. If you have multiple stakeholders, the RACI matrix can help.

In the columns you list who is Responsible (R), who is Accountable (A), who needs to be consulted (C) before taking the decision and who needs to be informed (I) of the decision.

In the rows, you list the key decision areas. It is important that you do not go further in certain team roles. The team is either doing it as a team, but you do not delegate certain decisions to a certain team member.

R
Responsible
A
Accountable
C
Consulted
I
Informed
deciding on vacations Individual Team Member Line Manager Team Team
homeoffice Team? Line Manager Team Line Manager
hiring external consultants Team Department Lead Team Lead Department Lead

Also, you should try to move the accountability as far as possible also to the team, not just being responsible.

Now, you create clarity who is accountable and who should do it (in most cases hopefully the team). Between those two now you can go further and clarify how far the delegation should go with delegation poker.

Thanks to Jenni Jepsen, who held an inspiring keynote at Agile Tour Vienna 2019 that motivated me to write this blog post.

Check out the upcoming training Intent-Based Leadership with Jenni Jepsen.

Step 3: Delegation Poker

Delegation is not a zero or one exercise. It is important to clarify how far a delegation should go. For example, if we hire external consultants, the department lead can expect that the team comes with a potential solution, but he keeps the budget authority and needs to sign it off. That would be delegation-level 3.

In order to clarify this, every team member and the involved manager or role who is accountable for a decision are to be discussed gets a deck of cards. Now everyone decides, how far they would expect that the accountable person delegates that decision to the team.

Like with planning poker this usually leads to good discussions and clarifications.

Step 4: Instepct & Adapt

I would suggest that you create an information radiator and use a delegation board on the wall where you see all the time what your delegation rules are. If you need to change it, do it and if you need to add further key decision areas do it on-the-job, for example during team retrospectives.

Hints and Tips

I would not necessarily start with that exercise before you set up the teams, but explain to the teams that we start to collect key decision areas on-the-job when we see that there is a problem. This avoids endless discussions before there is actually a problem.

If you face the situation that there is no real wish to put autonomy to the team, stop the exercise and work on the reasons why before.

The reason why I introduced the RACI matrix next to delegation poker is that delegation poker only allows for two roles, like manager and team playing it but the RACI matrix can show multiple stakeholders at once.

The goal is not to draw the lines but to reveal hidden assumptions and misconceptions.

Thanks to Jenni Jepsen, who held an inspiring keynote at Agile Tour Vienna 2019 that motivated me to write this blog post.

Check out the upcoming training Intent-Based Leadership with Jenni Jepsen.

References

Appelo, J. (2016). Managing for Happiness: Games, Tools, and Practices to Motivate Any Team. John Wiley & Sons, Inc.

Denning, S. (2018). The Age of Agile : How Smart Companies Are Transforming the Way Work Gets Done. Retrieved from http://sbiproxy.uqac.ca/login?url=http://international.scholarvox.com/book/88852686

Agile Tour Vienna 2019

Erste Ankündigungen für die Agile Tour Vienna 2019! Am Freitag, den 20. September findet die neunte Agile Tour Vienna in Wien statt und wir freuen uns spannende Vorträge und lebhafte Erfahrungen teilen zu dürfen.

Marcus Hammerberg bei der Agile Tour 2018

Wegen des positiven Feedbacks über den Veranstaltungsort wird auch dieses Jahr der FH Campus als Kulisse der Agile Tour Vienna dienen. Anders als in den letztens Jahren wird sie allerdings auf einen Freitag verlegt.

Mit seinen spannenden und inspirierenden Vorträgen, freuen wir uns besonders unseren ersten Keynote-Speaker ankündigen zu dürfen: Marcus Hammerberg. Er ist seit vielen Jahren Agile-Coach und hat an den unterschiedlichsten Orten und für die verschiedensten Institutionen gearbeitet – Teilnehmer vom letzten Jahr werden sich sicher an seinen Vortrag „The Bungsu Story – Inspirational Presentation“ (zum Video) erinnern. Im März hat er außerdem einen Workshop namens „Kanban in Action – Process Improvements Now! And forever!“ bei TechTalk in Wien gehalten.

Call For Proposals! Die Ausschreibung nach Keynote-Speakern hat begonnen! Sessions und Workshops sollten sich mit Themen aus einem der folgenden Bereiche befassen:

  • Successful Technical Practices
  • Terrific Transformations
  • Amazing Products
  • Positive Psychology of Agility
  • Reach out – Agile beyond IT

Zusätzlich solltet Ihr ein passendes Format für Eure Session wählen. Möglich sind beispielsweise:

  • Classical talk
  • Interactive Sessions/Workshops
  • Practitioner Report (case studies)
  • Young Talents

Neu in diesem Jahr:

  1. Die Dauer einer Session beträgt 30 Minuten.
  2. Das Q&A wird in einem separaten 30-minütigen Slot stattfinden, einer für die morgendlichen und einer für die nachmittäglichen Sessions. Dies soll dem Publikum etwas Zeit geben, über Deine Session nachzudenken und Fragen direkter zu stellen.

Young Talents:

Aufgrund der positiven Eindrücke des vergangenen Jahres werden wir wieder den speziellen Track „Young Talents“ haben, der sich der Unterstützung von Young Professionals widmet, die ihre erste Sitzung auf einer Konferenz abhalten.

Anforderungen, die für diesen Track erfüllt werden müssen, sind:

  • Du bist unter 30 Jahre alt.
  • Es ist Dein erster Vortrag auf einer Konferenz.
  • Deine Session ist ein Classical Talk oder Praxisbericht.

Unterstützung bekommst Du vor und nach der Agile Tour:

  • Feedback zu Deinem Vortrag, einschließlich der Möglichkeit, mit einem Experten Kontakt aufzunehmen.
  • Individuelles Coaching zur Vorbereitung auf Deine Session
  • Die Möglichkeit eine Probe vor einem kleinen Publikum abzuhalten, um Dir wertvolles Feedback zu geben.

Bis zum 30. Juni ist es möglich, Sessions einzureichen. Mehr Informationen zur Ausschreibung.

Tickets für die diejährige Agile Tour Vienna 2020


Webexpo in Prag: 4 Key-Take-Aways und die Verlängerung meiner Buchliste

Mitte September besuchte ich die Webexpo in Prag. Das Programm der Konferenz richtet sich sowohl an Webentwickler als auch an Designer und so waren die Themen dieses Jahr gestreut von Design Thinking, Story Telling, AI und Machine Learning über AR/VR bis hin zu ReactJS und Talks über Performance im Web. Ich fokussierte mich v.a. auf die design-lastigen Talks.

Kurz möchte ich die vielen Eindrücke in 4 Key-Take-Aways zusammenfassen:

  1. Divergent and Convergent working everywhere

In vielen Talks wurde die Nutzung des Design Thinking oder der Double Diamond als Basis des Design Prozesses sowohl explizit, als auch implizit thematisiert – von IBMs „Enterprise Design Thinking“, über Firefoxs Verwendung von Event Storming und Facebooks Vorgehen zum Gestaltungsprozess, bis zum Vorgehen bei MSD zur Workshopgestaltung. Immer geht es um die Phasen des konkreten Anfangs (z.B. klares Vision) und darauffolgend der breiten Ideensuche.

Design Thinking für die Gestaltung eines Workshops von MSD.

Dann geht es darum sich wieder fokussiert Ideen auszuwählen, diese prototypisch umzusetzen und zu testen. Der Einsatz von cross-funktionalen Teams wird dabei immer als wichtiger Bestandteil gesehen.

  1. Agile & UX – diverse maturity level

Agiles Vorgehen wird in der Community als Standard wahrgenommen und noch schnellere Iterationen z.B. in Design Sprints genutzt um mit noch schnelleren Feedbackzyklen Ideen zu erarbeiten und zu testen. Es gibt jedoch noch immer Unternehmen in denen die agile Vorgehensweise und dazu die Integration von UX in diesen Prozess – inklusive User Research und User Testing – keineswegs der Standard sind.

Um dies zu verdeutlichen als Beispiel ein präsentierter Kommentar einen Scrum Masters in einem Projekt: „We don’t need to ask people what they want. We are the experts.”– So sollte es aber schon für jeden im UX oder Produktentwicklung klar sein, dass die Einbindung der Benutzer den Kern für den Erfolg einer Entwicklung darstellt.

Agile und User Research – nicht immer beste Freunde.

Auch war es für den User Researcher schwierig zu verstehen, welche Vorteile die agilen Methoden bringen können und dass der User Researcher auch Teil des agilen Teams sein soll.

Dieses Beispiel zeigt, dass es wichtig ist das gesamte Team in ein Boot zu holen und mit einem Basiswissen auszustatten – sowohl zum Thema UX, als auch im Bereich der agilen Methoden.

  1. Stories, Curiosity & Microcopy to connect with users

Wie kann man den Benutzer und Kunden so erreichen, dass etwas „hängen“ bleibt. Ein Beispiel dafür war die gesamte Story um den „Dollar Shave Club“ und die Nutzung einer konsistenten „tone of voice“.

In dem Talk von Kinneret Yifrah über „Microcopy – how users will fall in love“ thematisierte sie die Wichtigkeit mit dem Benutzer wie in einem Gespräch zu interagieren und gab den Rat „Imagine the user is in front of you – how would you talk to her?“. Und auch hier sollte etwas Spaß und Freude berücksichtigt werden.

Statt mit der Aussage „Your browser is out of date” informiert eine Website “Love your vintage browser! Unfortunately, it is a little bit too vintage … “.

  1. AI/ML & Design for Good

Ein wichtiges Thema – welches mich schon auf den Konferenzen der letzten 1-2 Jahre begleitet – war der Fokus auf „Design for Good“. Also, dass es nicht nur darum gehen soll ein Problem zu lösen, sondern wie Dan Saffer sagte, auch eine humane Funktion zu gestalten:

„If your design makes people more generous, helpful, thoughtful, useful, beautiful, respectful, or kind, it’s good design.”

Ein explizites Praxisbeispiel in einem weiteren Talk dafür war eine Social-Network-App für das tschechische Olympische Team in Pyeongchang und wie sie versucht haben nicht (!) die Nutzungsdauer der App durch Benachrichtigungen oder Infos über Likes zu erhöhen. Sondern es ging darum das Gemeinschaftsgefühl und den Informationsaustausch zu verbessern – unabhängig davon ob dies nun online über die App oder offline passiert.

Evil-free social network für das tschechische Olympiateam.

Vor allem die Relevanz von „Design for Good“ zeigt sich im Bereich der AI bzw. Machine Learning, weil hier auch unbeabsichtigt ein Bias entstehen kann. In ihrem Talk „People & Algorithms: Building AI-Driven Features that don’t Cause Harm” hat Val Head von Adobe thematisiert, dass diese Biases aktiv adressiert werden müssen. D.h. sie empfahl auch ungemütliche Fragen zu stellen und dafür können auch die „Tarot Cards of tech“ (Shop, leider nur in den USA verfügbar) genutzt werden.

Buchlistenerweiterung

Und natürlich werden in fast alle Talks interessante Bücher erwähnt und wieso soll nur meine Buchliste länger werden:

  • The Man Who Lied to His Laptop: What We Can Learn About Ourselves from Our Machines – Clifford Ness, Carina Yen (Amazon)
  • Conversational design – Erika Hall (Book Website)
  • Microcopy – Kinnereth Yifrah (Book Website, Amazon)
  • Weapons of math destruction – Cathy O’Neil (Book Website, Amazon)
  • Technically wrong – Sara Wachter-Boettcher (Book Website)
  • Design for real-life – Eric Meyer & Sara Wachter-Boettcher (Book Website)
  • Wired for speech – Clifford Nass, Scott Brave (Book Website, Amazon)
  • Newsjacking – Jan Burkhart, Grant Hunter (Amazon)

Conference Review of WebExpo

Generell eine sehr tolle Veranstaltung mit interessanten Speakern und das Preis-Leistungsverhältnis ist sehr gut. Auch war es die erste Konferenz, die mir sehr stark durch ihre Familienfreundlichkeit aufgefallen ist – einige Babys waren dabei und für die Größeren gab es eigene Workshops.

Die gesammelten Aufzeichnungen der Talks werden auch zur Verfügung gestellt und hier gibt es einen weiteren detaillierten Eventbericht von Juho.

Agile at Scale – wie es Spotify gemacht hat

Schon 2016 konnte Joakim Sundén von Spotify mit seiner Keynote die Community auf der Agile Tour Vienna begeistern! Am 25. und 26. Mai 2020 bieten wir  nun einen neuen zweitägigen Trainingskurs mit ihm an: Agile at Scale – inspired by Spotify.

Aus dem Training:

„The Spotify Model“ of agile at scale has had a huge amount of attention in the agile community since it was first shared widely in 2012. Though never originally intended as a framework or model, the case study of Spotify’s approach to agile working has become a hit with a large number of organisations who have opted to imitate the method. This course will help you and your team to understand how and why it was optimized, the challenges that come with the method, and how companies can adapt and continue to evolve while employing this strategy of agile at scale.

Noch nicht überzeugt? Die Keynote gibt einen Überblick über Themen, die bei dem Training behandelt wurden.

Agile Tour 2017 Rückblick (+Fotos und Videos)