Beiträge

Agile at Scale: How „The Spotify Model“ came to life and how it can be applied in a remote-work environment

Joakim Sunden
Consultant at Crisp

Joakim Sunden was one of the Agile Coaches at Spotify working together with the CTO to develop a new approach to Agile at scale, aka “The Spotify Model” with Tribes, Squads, Chapters and Guilds. He is also a well-known figure in the agile community, having organized and spoken at many international conferences and community events over the years. In 2016 he held a keynote at Agile Tour Vienna, since then we partner with Joakim and also offer a training course about „The Spotify Model“. For this post, we asked Joakim how „the Spotify Model“ came to life and how it evolved since then.

How would you explain the Agile at Scale (Spotify Model) to someone who has never heard about it?

There’s no short answer to that so you’ll have to bear with me for some background story. Back in 2011 when I joined Spotify we had fewer than ten teams, or squads as we could come to call them. But we already experienced some growing pains and we knew that we would grow a lot as we had big plans and a lot of VC funding. We wanted to desperately avoid the increased bureaucracy and slow speed many of us had experienced with other big companies so we tried to come up with a new way of organizing ourselves to stay agile even at scale.

At it’s core it’s all about trusting the people you hire to do a great job and support them the best you can without getting in their way. This is why we called the core of our org an “autonomous squad”, a 5-10 people small and empowered product development team who are free to make a lot of more choices than any other team I had ever worked with in the past. Not just how to build things, but also to a large extent what to build. Within bounds of course.

One example of such bounds is the product direction, or goal, of your tribe. Each squad was part of a mission, or product area, called a “tribe”, together with maybe four to ten other squads. The Tribe Trio leadership would set a direction in dialogue with the squad and upper management, within which the squads would have freedom to explore different experiments to push the metrics the right way. Leadership is all about supporting you, making sure you have clarity of direction and everything you need to get there, in terms of skills, resources, decision power, etc.

That’s also true for your closest manager who leads the functional area, or Chapter as our name was, you’re part of together with 5-10 coworkers with similar skill sets. Kind of a matrix model where the manager is a servant leader responsible for your development and success rather than for making decisions and relaying information, and so on.

On a surface level this is what most people understand as “the Spotify Model”; Squads, Chapters, and Tribes. Because that’s the visible most apparent structural parts of it. In practice it’s much more about mindset, culture, leadership, all those things that’s really different and makes it tick, but harder to observe and understand. And that’s what we drill down into in the course. That and the finer mechanics of some of what we learned along the way and from living with this model and evolving it  for several years.

So the first white paper on the Spotify model came out in 2012. What has happened since then?

Wow, a lot really… One of the most concrete things that we abandoned rather quickly after the paper came out was the idea that a Chapter Lead, that is, an engineering manager, should work 50% as a manager and 50% as an individual contributor in a squad. That simply didn’t work, it was too much. Which is not to say that it’s not the right thing for other companies to be doing, but it didn’t work for us with very high expectations on the people development part of the role.

Great experience. Completely realistic view. Down to earth presenter.

– Attendee feedback, Agile at Scale Workshop with Joakim Sunden in 2019

This is by the way a reason I don’t want to talk a lot about changes to Spotify’s way of working, since people seem to perceive it as some kind of evolution and “what Spotify’s doing now must be so much better than the old white paper, so let’s take a short cut and go straight to where they are now”. How Spotify evolved is not necessarily the way your organization needs to evolve. What was working well at some point in one context may not be working well in another context. In an organizations of Spotify’s size there’s now also multiple different solutions to similar problems in different parts of the company. Some held on to the Chapter Lead model while others tried other approaches to solve for other problems, reach other goals.

So rather than talking about the evolution of a specific model we spend a lot of time in the course talking about what we learned from different things, the thinking behind it, how things evolved. All with the goal of course participants being better equipped to solve their own issues themselves when they get back to work. Using Spotify as an inspiration, for different types of solutions, but also the approach to change and problem solving that we applied. And not just Spotify, we drew inspiration from plenty of sources ourselves, and so should you of course.

Can the Spotify model also be applied in a remote work environment?

Absolutely! Spotify was early on a distributed company with product development in Stockholm, Gothenburg, New York and San Francisco. Later we added Boston, where I lived and worked for a few years, and more recently London. So a remote work environment was there pretty much from the start for me.

Working in a remote environment it’s even more important to let go of control and trust your people and teams to work autonomously to solve problems. It’s even more important to have good practices in place for collaborating and communicating, to create clarity of direction and communicate progress when working remotely.

When I left Spotify and started consulting with companies I was shocked to learn how bad most of them were at remote work practices and how many companies just lack the tools to be able to collaborate efficiently in a remote environment. Even though the course is very little about remote work practices per se, indirectly it’s a lot about supporting that way of working. Since we’re also running it remote, participants will be able to learn some really good tools for remote workshops, should they not already be familiar with them.  

Wie finde ich den passenden agilen Anbieter für mein Projekt?

Der Preis ist häufig das entscheidende Kriterium, wenn es um die Auswahl eines agilen Anbieters geht. Denn es ermöglicht, die verschiedene Angebote einfach zu vergleichen und so eine scheinbar sichere Auswahl zu treffen. Zumindest auf den ersten Blick. 

Wenn Sie jedoch die Eignung des Anbieters außer Acht lassen oder zu gering bewerten, können sich die anfänglichen Einsparungen schnell revidieren. So kann es sein, dass der Anbieter die Anforderungen des Projektes nicht erfüllt und das Projektteam darunter leidet. Wenn Sie am falschen Ende sparen, sind die zusätzliche Kosten und der Zeitaufwand deutlich höher, als die Einsparungen zu Beginn. 

Wir zeigen Ihnen, welche Qualitätskriterien aus unserer Sicht wichtig für agiles Vorgehen sind und wie Sie in einem strukturierten Prozess den richtigen Anbieter für Ihr agiles Projekt auswählen können.

Kriterien für die agile Anbieterauswahl

Es ist wichtig, dass Sie sich bereits vor dem Auswahlprozess mit dem Thema Qualitätskriterien beschäftigen. Nur so können Sie wissen, worauf Sie bei den Auswahlgesprächen achten müssen. Unser Meinung nach sollten Sie auf jeden Fall folgende Kriterien berücksichtigen:

  • Erfahrung Agilität: Je mehr Erfahrung ein Anbieter mit agilen Methoden hat, desto besser. Nur wenn eine „Agile Culture“ gelebt wird, kann auch eine agile Projektentwicklung erfolgreich sein.
  • Eingespieltes Team: Ein eingespieltes Team ist einem neu zusammengestellten Team vorzuziehen. Denn eingespielte Teams können oftmals ein Vielfaches der Produktivität eines neuen Teams erzielen. Bei längeren Projekten sollten Sie außerdem die Fluktuation im Team berücksichtigen. Wir kennen die Thematik insbesondere bei Offshore-Teams, in denen einzelne Entwickler jederzeit getauscht werden können.
  • Direkte Kommunikation: Dieser Faktor ist für agile Projekte besonders wichtig. Es muss sichergestellt sein, dass Ihre Experten mit den Experten des Anbieters direkt zusammenarbeiten können — im Idealfall sogar im gleichen Scrum-Team. Aus unserer eigenen Erfahrung kommt es häufig zu Problemen, wenn es zu viele Übergaben zwischen den einzelnen Teammitgliedern gibt. Entscheidungen müssen schnell, ohne langwierige Entscheidungswege getroffen werden können. 
  • Erfahrung Domäne: Die Erfahrung in der Domäne spielt ebenfalls eine wichtige Rolle — vor allem auf dem Level der Teammitglieder. Es werden oft internationale Referenzen genannt, das entsprechende Team besitzt diese Erfahrungen jedoch nicht. 
  • Culture Fit: Es wichtig, das Mindset und die Entwicklungsprozesse des Anbieters zu verstehen. Sie sollten im Vorfeld prüfen, inwieweit diese zum eigenen Unternehmen passen und eine enge Zusammenarbeit ermöglichen.
  • Grad der Abhängigkeit: Es ist sinnvoll, zu überlegen, wie man den Grad der Abhängigkeit zum Anbieter auch im weiteren Verlauf gering hält. Eine Möglichkeit ist es, auf offene Standards zu setzen. Diese ermöglichen zu einem späteren Zeitpunkt einen leichteren Anbieter wechseln bzw. eigene Entwickler zu schulen, die am Produkt entwickeln. 
  • System Architektur: Es ist entscheidend, dass die Architektur der neuen Lösung zur bestehenden Systemlandschaft passt. Ein völlig neuartiges System mit neuen Technologien erhöht die Komplexität und erschwert später die Wartung, wenn die Skills nicht ausreichend innerhalb der Organisation vorhanden sind. Die Abhängigkeit zum Hersteller wird dadurch auch erhöht.
  • Wartung: Nachdem die Software entwickelt ist, beginnt die Wartungsphase. Diese dauert bekannterweise weitaus länger als die Entwicklung. Daher sollten Sie die Strategien der Anbieter für diese Phase prüfen und testen, wie schnell sie z. B. auf unvorhergesehene Fehler wie Produktions-Incidents reagieren.

Neben den Qualitätskriterien sollten Sie als Kunde Ihre wichtigsten NFRs (Nichtfunktionale Anforderungen; engl. Non-functional Requirements), wie Security, Skalierbarkeit, Testbarkeit  kennen. Nur so können Sie im Auswahlprozess überprüfen, ob die Anbieter diese erfüllen können und diese direkt kommunizieren. Andernfalls kann es zum Beispiel sein, dass Sicherheitsanforderungen zu deutlich höheren Kosten oder im schlimmsten Fall gar nicht vom System umgesetzt werden können. Bekannterweise beeinflussen NFRs die System-Architektur stärker als funktionale Anforderungen. Daher kann es im schlimmsten Fall sein, dass ein Produkt diese NFRs gar nicht mehr umsetzen kann.

In 4 Schritten zum passenden agilen Anbieter 

Diese Vorüberlegungen bieten die Grundlage für einen strukturierten Prozess, mit dem Sie die Anbieter anhand der wichtigsten Kriterien in vier Schritten auswählen können. 

1. Vorauswahl treffen

Wenn Sie eine Ausschreibung für ein agiles Projekt starten, werden Sie eine Reihe von Angeboten erhalten. Im ersten Schritt geht es darum, eine Vorauswahl der Angebote vorzunehmen. 

In der Regel wird die Vorauswahl von der Einkaufsabteilung getroffen. Diese wählt die Anbieter anhand der zuvor beschriebenen Qualifikationskriterien und des Preises aus. 

 2. Intensive Gespräche führen

Nachdem die Vorauswahl getroffen wurde, finden intensive Gespräche zwischen Ihren Experten und den Experten des Anbieters statt. Diese Gespräche dienen dazu, den ersten Eindruck zu validieren. 

Zusätzlich können in dieser Phase Anforderungen, wie die NFRs angesprochen werden, um den Anbietern eine detaillierte Vorstellung zu geben, was von ihm während der Projektumsetzung erwartet wird.

 3. Prototypen-Phase durchführen

Die Prototypen-Phase ist eine entscheidende Phase, die jedoch häufig nicht gemacht wird. Vor allem, wenn Sie mit den Anbietern noch nicht zusammengearbeitet haben, sollten Sie diese Phase auf keinen Fall überspringen. 

Die Prototypen-Phase wird im Idealfall sogar mit mehreren ausgewählten Anbietern durchgeführt. Das Ziel dieser Phase ist es, die Zusammenarbeit anhand von lauffähiger Software zu beurteilen. Dadurch erhalten Sie ein viel besseres Verständnis, ob die Zusammenarbeit mit einem Anbieter funktioniert und ob alle Qualitätskriterien erfüllt werden können. 

Wichtig hierbei: Sie sollten bei der Prototypen-Phase darauf achten, dass diese mit dem finalen Team durchgeführt wird. Die Mitarbeiter, die für die spätere Produktentwicklung zuständig sein werden, sollten bereits in dieser Phase in der finalen Konstellation am Prototypen arbeiten.

4. Produktentwicklung starten

Die Software, die während der Prototypen-Phase entsteht, sowie das Feedback der Experten über die Zusammenarbeit mit dem Anbieter dient als Entscheidungsgrundlage, um die Auswahl weiter zu reduzieren. Am Ende dieser Phase sollten Sie einen Anbieter auswählen, mit dem Sie die Produktentwicklung durchführen.
Bevor es jedoch in die Entwicklungsphase geht, steht die Vertragsverhandlung an. Bei agilen Projekten gibt es einige Fallstricke, auf die Sie bei der Vertragsgestaltung achten sollten. Wir haben Ihnen die wichtigsten Tipps zusammengefasst, um eine solide Vertragsgrundlage für Ihre agilen Projekte zu schaffen.

Der Auswahl-Funnel zur Findung des passenden agilen Anbieters

Der Preis ist nicht das entscheidende Kriterium

Der Preis ist in der Regel nicht das beste Auswahlkriterium, selbst wenn es auf den ersten Blick so scheint. Es sich wichtig, sich im Vorfeld über die wichtigsten Qualitätskriterien bewusst zu sein und diese in einem strukturierten Prozess für die möglichen Anbieter zu validieren.

Der folgende Fragenkatalog bietet Ihnen dabei eine erste Hilfestellung zur Beurteilung der Anbieter-Qualität:

  • Wie groß ist die Erfahrung des Anbieters mit agilen Methoden?
  • Ist sichergestellt, dass ich ein eingespieltes, erfahrenes Team bekomme? Habe ich direkten Einfluss auf die Personen, die in meinem Team arbeiten?
  • Ist eine direkte Kommunikation der Teammitglieder zwischen Kunde und Anbieter sichergestellt?
  • Hat der Anbieter und insbesondere das Team, das mein Projekt umsetzt Erfahrung in meiner Domäne?
  • Bei länger laufenden Initiativen: Wie hoch ist die Fluktuation der Personen im Team?
  • Kennen Sie Ihre nicht-funktionalen Anforderungen?
  • Wie direkt können Sie mit dem Umsetzungsteam kommunizieren?
  • Ist das Umsetzungsteam vielleicht direkt Teil des eigenen Teams?
  • Wie gut ist der agile Anbieter in der Wartungsphase?

Haben Sie weitere Fragen zur Auswahl von agilen Anbietern?

Oder wollen Sie in Ihrem Unternehmen ein Umfeld entwickeln um die Arbeit nach agilen Methoden zu ermöglichen?

Bitte kontaktieren Sie mich gerne via eMail oder auf LinkedIn mit Ihren Fragen.


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.

4 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 vier 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.


Haben Sie weitere Fragen zur Umsetzung von Projekten mit agilen Verträgen?

Oder wollen Sie in Ihrem Unternehmen ein Umfeld entwickeln um die Arbeit nach agilen Methoden zu ermöglichen?

Bitte kontaktieren Sie mich gerne via eMail oder auf LinkedIn mit Ihren Fragen.


Online Planning and Collaboration in Multiple Teams (Kostenloser 90-min. Remote-Workshop)

Ole Jepsen
Enterprise Agile Coach | Scaled Planning Advisor |

Um die Entwicklung von Produkten und Dienstleistungen zu beschleunigen und marktfähig zu bleiben, setzen viele Teams auf agile Methoden.

Bis vor wenigen Wochen war es üblich sich in großen Runden in Meetingräumen zum PI Planning, Face2Face zu treffen, um die Hürden der Planungs- und Koordinierungsaufgaben zu besprechen.

Dann kam Covid-19 und die Frage wie diese großen Planungssessions nun durchzuführen seien. Verschieben und Momentum verlieren, oder online durchführen?

Ole Jepsen wird in diesem Remote-Workshop seine Erfahrung im Bereich Online-Planung weitergeben. Sowohl aus Pre-Corona-Sicht (Teams in unterschiedlichen Ländern verteilt) und Post-Corona-Sicht (alle zu Hause am Laptop).

„Set up the collaboration board exactly as you would set up the physical conference room“ – Tip by Ole Jepsen

Die Gute Nachricht ist, dass Online-Planung (PI Planning) sehr wohl online gut umsetzbar ist. Die Durchführung erfordert eine gute Vorbereitung, die richtigen Tools und ein paar Tipps und Tricks.

An wen richtet sich dieser Online-Workshop?

Idealerweise haben Sie Erfahrung in der Zusammenarbeit mit agilen Methoden, Scaled Agile, SAFe, LESS, oder haben in der Vergangenheit schon an PI-Planning-Sessions teilgenommen.

Nehmen Sie an diesem interaktiven Remote-Workshop teil und lernen, wie Sie Ihre Online-Planungs-Sessions erfolgreich durchführen können.

Weitere remote Workshops finden Sie auf unserer Trainingsseite.


Rückfragen & Kontakt

Milena Krnjic

milena.krnjic@techtalk.at
LinkedIn

Hinweis: Der Workshop wird in englischer Sprache abgehalten. Für die Durchführung des Workshops wird die Videokonferenz-Lösung Zoom herangezogen, sowie das Tool Metro Retro. Sie müssen keine Software für die Teilnahme installieren. Falls Sie noch keinen Metro Retro-Account haben, erstellen Sie bitte im Vorfeld einen. Ein Zoom Account ist nicht notwendig. Für Zoom verwenden Sie am besten den Browser Chrome.


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, 25.-28. Mai 2020

Agile Development techniques: Approval Testing

mit Emily Bache, 8.-12. Juni 2020

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.

Agile Breakfast: Mut zur Innovation in regulierten Branchen

Es ist möglich innovativ zu sein und dennoch im Einklang mit den Richtlinien zu agieren.

In diesem Agile Breakfast wird uns David Dlugos (UNIQA) von seinen Erfahrungen im Kampf für Innovation innerhalb der rechtlichen und regulatorischen Minenfelder der Versicherungswirtschaft berichten:

„Es geht darum herauszufinden, wie man die Grenzen der Regulatorik ausloten bzw. testen und zu Gunsten von Kunden und Unternehmen umsetzen kann. Dazu bedarf es des richtigen Mindsets im Unternehmen, Kreativität, Mut, intelligenter Prozesse und einer überzeugenden Nutzen-Argumentation für alle Beteiligten.

Anhand von Beispielen aktueller Herausforderungen aus der DACH-Region erzähle ich, wie ein Lern- und Entwicklungsprozess für Versicherer und ähnliche Branchen mit regulatorischen Mechanismen ausschauen kann“.

Wir laden Sie zu einem Vortrag und anschließendem Erfahrungsaustausch mit der agilen Community ein.

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!

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 LeadDepartment 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


Agile (Tour) for Managers: Ausgewählte Beiträge für „Organisationsjunkies“

Sie sind nicht direkt aus der IT, interessieren sich aber trotzdem für „Agile“? Sie vermeiden Buzzword-Bullshit-Bingo Konferenzen und Methoden-Nerd-Vorträge? Sie interessieren sich vielmehr für authentische Praxisberichte und Überlegungen?

Christian Hassa on stage beim Opening der Agile Tour Vienna 2017

Wir glauben wir haben etwas für Sie: die von TechTalk initiierte und bereits zum 8. Mal stattfindende Agile Tour am 6.10.2018 in der FH Campus Wien bietet kompakt an einem Tag renommierte Speaker mit Inhalten, die von einem unabhängigen, großen und erfahrenem Review Team kuratiert sind. Der Eintritt zur Agile Tour ist mit EUR 99 extrem niedrig  (Tickets kaufen), weil wir kommerziell nur die reine Kostendeckung anstreben, eben um die Inhalte sauber zu halten.

Folgende ausgewählte Beiträge empfehlen wir speziell für „Organisationsjunkies“ ohne direktem Bezug zu IT- und Softwareentwicklung:

Kevlin Henney

Agilität bringt Wendigkeit, nicht Schnelligkeit. Auf geradem Weg mit konstantem Ziel ist Agilität nicht so vielversprechend wie in Situationen, in denen probiert und laufend flexibel angepasst werden muss, um im Spiel zu bleiben. Henney ist ein gefragter internationaler Keynote Speaker, hier finden Sie seinen „Old is the New New“ Talk von der GOTO 2018. Seine Agile Tour Keynote.

Christian Hattinger (Agile Coach @ mySugr) erzählt über den beeindruckenden Weg des Wiener Startups während der letzten Jahre und die Transition von 4 auf 120 MitarbeiterInnen. Vom Startup zum etablierten agilen Unternehmen in kurzer Zeit. Abstract

Rene Pachernegg, (CTO @ APUS) erzählt seine Case Study von APUS im Talk „Hinfallen, Aufstehen, Krone richten, Weitermachen“. Was waren die 8 wichtigsten Lektionen der APUS auf ihrer Reise zum agilen Unternehmen seit 2010? Einblicke in Erfahrungen aus Misserfolgen in den Bereichen Krisenprojekte, Recruiting, Gehaltspolitik und mehr werden hier versprochen. Abstract

Unsere „Young Talents“ Karin Haberleithner, Sabina Lammert und Laura Fitzgerald beschäftigen sich in ihren 3 Vorträgen mit Erfolgsrezepten für agile Unternehmen und Organisationen. Talk 1, Talk 2 und Talk 3

Markus Hammarberg (Agile Coach) erzählt von seinen Erfahrungen im „Salvation Army hospital“ in Bandung Indonesien. Wie er durch die Anwendung agiler Methoden ein Krankenhaus unterstützen konnte und damit nicht nur die Einrichtung gerettet wurde … hier kann man sich einen inspirierenden Vortrag erwarten, frei von jeder Technik. Abstract

Florian Hackl-Kohlweiß (Organisational Development @ mySugr) ergänzt die mySugr Story um Erfahrungen aus dem HR-Bereich, dem Business- und Produkt Development und dem Anspruch, in einem agile Mindset eine gute Arbeitsumgebung für kreative Problemlöser zu schaffen – trotz der Tätigkeit in einem sehr regulierten Gesundheitsmarkt. Abstract

Gojko Adzic (Partner @ Neuri Consulting LLP) und Christian Hassa (Managing Partner @ TechTalk) kombinieren in ihrem Talk „Max Impact – Min Erffort“ Studien und Erfahrungen zu nützlichen Praxistipps um das Tempo organisationaler Adoption zu erhöhen, gängige Fehler zu vermeiden und Ziele schneller zu erreichen. Abstract

Robert Finan (Agile Coach @ TechTalk) meistert die beiden sowieso bereits schwierigen Thema „Agile Coaching“ und „Humor“ und erklärt den Witz hinter seinen „Agile Drill Sergeant“ Cartoons. Möglicherweise handelt es sich eher um Schmerzen aus seiner Praxiserfahrung als „Frontline Coach“, mit denen er in dieser Form „drüberlacht“? Achtung, hier wird oft und auch über Manager gelacht. Macht aber nichts, es wird sich eh niemand angesprochen fühlen. Abstract


Wir würden uns freuen, Sie bei der Agile Tour begrüßen zu dürfen und möchten darauf hinweisen, dass wir bisher immer ausgebucht waren – noch gibt es Tickets, aber das kann sich jetzt schnell ändern.