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

/0 Kommentare/in /von

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.

Approval Testing: What It Is and How It Helps You To Manage Legacy Code

/0 Kommentare/in /von

Emily Bache is a Technical Agile Coach, she helps software development teams to get better at the technical practices needed to be agile, including Test-Driven Development, Refactoring, and Incremental Design. Emily is known as the author of the book, “The Coding Dojo Handbook”. For the second time, we organize a training course with Emily on Approval Testing. In this email interview we asked Emily what counts as legacy code, how to get into approval testing, and what her upcoming book will be about.

What is the optimal way of learning Approval Testing? What is the role of Gilded Rose Kata and other exercises in this process? 

Approval Testing is a style and approach to writing automated tests that changes the way you verify behaviour. Basically, the ‘assert’ part of the test. As with any new tool or approach, it helps to have actual code examples to play with when you’re learning it. Once you start to see it in action then you’re bound to have lots of questions so it’s good to have people around you to discuss it with.

The Gilded Rose Kata is a fun little exercise that I maintain. It actually comes with approval tests, as well as being translated into about 40 programming languages. Whatever your coding background and language preferences, you can try it out and see how it works for yourself. When you’ve done that, you should easily be able to find other people to discuss it with, since it’s quite a popular exercise. For example Ron Jeffries recently wrote 13(!) blog posts about his experience with it.

You talk about refactoring and handling legacy code? What is actually legacy code? How would you define it? 

Many developers struggle with code they inherited which has poor design and lacks automated tests. On their own, any one of those difficulties could probably be overcome, but in combination developers get a kind of paralyzing fear of changing the code. That’s how I would define legacy code. Code that you need to change but you’re afraid to in case you break it.

The antidote to that fear, I find, is feedback. High-quality feedback telling the developer when they are making safe changes. The feedback that gives them the confidence to improve the design and get in control. Approval testing is one way to get that feedback – you create regression tests that give you good information when behaviour changes.

Course Outline & Registration

What are the main things one should know before starting working with Approval Testing? 

Since it’s a style of automated testing, it helps to have experience with unit testing already, perhaps with JUnit or similar. Approval Testing is often used in larger-granularity tests too, so experience with tools like Selenium or Cucumber would give you a good perspective, although it works a bit differently. This way of testing also fits extremely well into Agile methods, BDD, and Specification by Example. If you are working in a more traditional process, you may find adding these kinds of tests will help you to increase your agility.

For which situations is Approval Testing the best solution? When shouldn’t it be used? 

If you’re facing legacy code, this can be a great addition to your strategy for getting control. I wouldn’t discount it for new development though, particularly if your system will produce some kind of detailed artifact where the user really cares about how it looks. For example I’ve seen this approach used to verify things like invoices, airline crew schedules, 3D molecular visualizations, and hospital blood test results.

Of course there are situations where I wouldn’t use Approval Testing, for example where the output is a single number – the result of a complex calculation. If you can calculate the expected result before you write the code, testing it with an ordinary assertion is a sensible approach.

Can Behaviour Driven Development be considered as the future of the industry and Approval Testing as an essential part of it? Why is it so?  

The main priority of BDD is to improve collaboration and communication so we build the right software. In my experience Approval testing promotes good conversations. I’m giving a keynote speech at Cukenfest soon, (a conference about BDD), and I’m going to be talking about exactly this topic. For the test automation part of BDD most teams use the Gherkin syntax with Cucumber or SpecFlow. I think you can use Approval testing in a similar way.

You have been working on this topic for a while  – what excites you about it? 

There is so much potential for this technique! I see a lot of legacy code out there, and I see a lot of test cases that are unnecessarily difficult to maintain. If I can spread these testing techniques to even a small proportion of all those places it will make a huge positive difference to the quality of the software in the world.

You wrote a book about Coding Dojo, what can we expect from your follow-up book? 

The motivation for my upcoming book “Technical Agile Coaching” is largely the same as for the previous one – I write for people who want to make a difference and improve the way software is built. In 2011 I published „The Coding Dojo Handbook“ which is full of advice and experiences setting up a forum for practicing coding skills. You can see my new book as an expansion of those ideas, seasoned with ten years of additional experience.

The focus of the coaching method I describe in the book is specifically on technical practices and how people write code. There are two main elements to the coaching. Firstly teaching techniques via interactive exercises and code katas. Secondly coaching a whole team to work effectively together as they do mob programming.

Course Outline & Registration

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

/0 Kommentare/in /von
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“ cam 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.

Course Outline & Registration

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.  

Course Outline & Registration

WZG verstehen und umsetzen – Barrierefreiheit in der öffentlichen Verwaltung

/0 Kommentare/in /von

Vergangenes Jahr wurde für die Barrierefreiheit in der öffentlichen Verwaltung wieder ein wichtiger Schritt gemacht – das Web-Zugänglichkeits-Gesetz (kurz: WZG) wurde im Juli 2019 in Österreich verabschiedet. 

Ähnlich der BIT-Verordnung in Deutschland wurde nun eine verpflichtende Regelung geschaffen, dass die Webseiten und mobilen Anwendungen des Bundes bzw. vom Bund finanzierten Einrichtungen die Anforderungen an die Barrierefreiheit erfüllen müssen und vor allem auch durch welche Aktivitäten dies gewährleistet werden soll. 

Anforderungen an die Barrierefreiheit laut WZG  

Im WZG verweisen die Anforderungen an die Barrierefreiheit vor allem auf die bereits länger festgelegten Richtlinien und damit gilt als Richtschnur die Erfüllung der Stufe AA der „Richtlinien für barrierefreie Webinhalte Web – WCAG 2.0“.  

In der Folgeabschätzung im Rahmen des Gesetzgebungsprozesses wurde davon ausgegangen, dass die Einführung des WZG keine zusätzlichen Kosten verursacht, da bereits seit 2004 mit dem E-Government-Gesetz behördliche Internetauftritte so zu gestalten sind, dass internationale Standards über die Web-Zugänglichkeit erfüllt werden. Aus meiner Sicht ist dies etwas zu kurz gegriffen, da nicht die volle Breite aller Angebot die Barrierefreiheit mit Stufe AA bisher berücksichtigt hat bzw. nun explizit auf mobile Anwendungen mit eingeschlossen sind. 

Aufgaben im Zusammenhang mit der Web-Zugänglichkeit 

Neben der Sicherstellung der Barrierefreiheit an sich, ist auch festgelegt, welche Aufgaben im Zusammenhang mit der Web-Zugänglichkeit zu erfüllen sind. So sind unter anderem die Mitarbeiterinnen und Mitarbeiter zum Thema barrierefreien Zugang zu schulen und zu sensibilisieren.

Darüber hinaus muss eine Erklärung zur Barrierefreiheit im Internet veröffentlicht werden – vergleichbar etwa mit der Datenschutzerklärung. Mit dieser Erklärung wird unter anderem dargelegt inwiefern die Anforderungen zur Barrierefreiheit erfüllt werden und wie dies überprüft wurde. Auch kann dargelegt werden wieso Anforderungen nicht erfüllt wurden, wenn die Behebung eine unverhältnismäßige Belastung für die Einrichtung darstellen würde. 

Screenshot der Barrierefreiheitserklärung von oesterreich.gv.at  

Wissen im Bereich Barrierefreiheit 

Mit der Umsetzung von Anwendungen vor allem im öffentlichen Bereich setzt sich unser Team schon lange mit dem Thema Accessibility und Barrierefreiheit auseinander. Veronika Winter hat letztes Jahr zum Beispiel im Rahmen der Projektarbeit intensiv mit den aktuellen Anforderungen des BIT-V auseinandergesetzt.   

Auch im Bereich des Web-Zugänglichkeits-Gesetzes unterstützen wir gerne mit einer Statuserhebung mit konkreten Verbesserungsvorschlägen, einer individuellen Beratung oder Schulung.

Fragen Sie einfach unverbindlich bei Claudia Oster an.  

  • User Experience & Design Thinking Newsletter

    Jetzt abonnieren und keine Ausgabe verpassen. Max. 4 Ausgaben im Jahr.

TechTalk Bootcamp – Einblick in das Onboarding von neuen MitarbeiterInnen

/in /von

Aller Anfang ist schwer – jedoch nicht der Arbeitseinstieg in die TechTalk. Als wesentlicher Teil des Onboardings begeben sich neue MitarbeiterInnen jedes Jahr in ein zweitägiges Bootcamp. Dort werden diese auf spielerische Art und Weise schnell mit dem Unternehmen und deren Prozesse vertraut gemacht.

Die Teilnehmer verbringen zwei volle Tage abseits des Arbeitsalltags an einer externen Location gemeinsam mit langjährigen MitarbeiterInnen der TechTalk aus verschiedensten Rollen. Wie die TechTalk arbeitet, was die Unternehmenskultur ausmacht und welche Methoden angewandt werden, sind nur einige von ganz vielen Themen, die hierbei behandelt werden. Neuen MitarbeiterInnen der TechTalk wird so in einem spannenden Rahmen ein unkompliziertes Kennenlernen über Teamgrenzen hinweg ermöglicht.

Für einen first-hands Einblick in das Onboarding der TechTalk und insbesondere ins Bootcamp haben wir Lisa, Thomas und Verena zum Interview gebeten. Lisa hat vor kurzem als Praktikantin in den Softwareentwicklung bei uns begonnen, Verena als Project Manager und Thomas als Senior Project Manager.

Wie fandet ihr den Onboarding-Prozess bei TechTalk?

Thomas: Einen so umfassenden, aufwändigen Onboarding Prozess wie bei TechTalk habe ich bisher noch nicht erlebt. Vom Buddy, der einen den ersten Arbeitstag komplett begleitet, über die zahlreichen Präsentationen zum Vorgehensmodell der einzelnen Fachbereiche mit anschließender Diskussion, bis hin zum zweitägigen Bootcamp – man merkt, wie wichtig es bei TechTalk ist, einen gemeinsamen Spirit zu entwickeln und zu leben.

Lisa: Der Einstieg in einen neuen Job kann manchmal schwer sein, überhaupt wenn es der erste richtige Job nach dem Studium ist. Bei TechTalk beginnt der Onboarding-Prozess schon vor dem ersten Arbeitstag und so fühlt man sich von Anfang an gut aufgehoben und willkommen. Durch das Buddysystem hat man auch immer jemanden, der einem mit Rat und Tat zu Seite steht und hilft, die Prozesse des Unternehmens kennenzulernen.

Verena: Der Onboarding-Prozess bei TechTalk war sehr gut organisiert. Ich bin noch nie so schnell in einem Unternehmen „angekommen“. Das Willkommenspaket hat die Vorfreude auf den Job-Einstieg bei TechTalk erhöht. Nina, mein Buddy, hat mich sehr gut begleitet. Das hat mir geholfen, mich gut einzuleben.

Wie wichtig war für euch das Bootcamp zum schnellen Start in die TechTalk?

Thomas: Das Bootcamp war für mich vor allem zum Kennenlernen und dem Austausch mit Kolleginnen und Kollegen wichtig, mit denen ich in meiner täglichen Arbeit nicht viel zu tun habe. Trotzdem bzw. gerade deshalb gemeinsam in einem Team an einem Mini-Projekt die gelernten Prozesse durchzugehen, auf typische Herausforderungen zu stoßen und damit umgehen zu müssen, war eine tolle Erfahrung.

Lisa: Es war wahnsinnig spannend. Wir haben sehr viel über die verschiedenen Prozesse bei TechTalk erfahren und konnten diese auch in der Praxis anwenden. Es hat sehr viel Spaß gemacht, gemeinsam Aufgaben zu lösen und auch die anderen neuen KollegInnen und Kollegen näher kennenzulernen. Für mich war es der perfekte Abschluss zum Einstieg in die Firma und ich schätze es sehr, dass so viel Zeit und Ressourcen in neue Teammitglieder investiert werden.

Verena: Im Bootcamp haben wir einen Sprint im Schnelldurchlauf durchgespielt. Dabei war besonders interessant, dass ich die Rolle der Entwicklerin einnehmen durfte, was mir eine andere Perspektive auf das Projekt gab. Das Bootcamp war auch wichtig, um mein Scrum-Wissen zu vertiefen. Ich hatte noch nie die Gelegenheit, an einem Bootcamp in einem anderen Unternehmen teilzunehmen.

Was war dein Highlight des Bootcamps?

Thomas: Ein Highlight war das gemeinsame Escape-the-Room Social Event, das die Problemlösungsfähigkeiten in einem bunt zusammengewürfelten Team einmal mehr auf die Probe gestellt hat.

Lisa: Das war unter anderem das Escape-the-Room Spiel am ersten Abend. Hier hatte man die Möglichkeit, die KollegInnen mal in einem etwas privaterem Setting kennenzulernen und beim gemeinsamen Bier danach, noch den ersten Tag im Bootcamp Revue passieren zu lassen.

Verena: Zusätzlich zu meinen ersten Erfolgen als Entwicklerin war das Bootcamp eine großartige Gelegenheit, sich noch mehr zu vernetzen. Dies funktionierte besonders gut mit dem Escape-the-Room Spiel sowie dem Bier danach.

Möchtest auch du Teil der TechTalk werden? Wirf einen Blick auf unsere derzeitigen Jobausschreibungen oder kontaktiere uns direkt.

Auch in Zeiten von Corona und Homeoffice suchen wir Verstärkung für unser Team. Statt in unserem Office vor Ort finden die Bewerbungsgespräche derzeit per Video Call statt.

Natürlich kannst du dir vorab auch selbst ein Bild über uns machen, besuche unser Kununu-Profil oder stöbere durch unsere Karriere-Seite.

Weitere Blogbeiträge, um TechTalk besser kennenzulernen:

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

/in /von
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.

Jetzt Anmelden

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!

/in /von

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

Automated Acceptance Testing and Story- Driven Development

mit Dave Farley, 22.-24. 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

/in /von

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.

Leider bin ich verhindert ...

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

Tricentis übernimmt SpecFlow

/in /von

Vor 10 Jahren wurde uns klar, dass Unternehmen durch die Digitalisierung immer schneller und kontinuierlicher auf Kundenbedürfnisse reagieren müssen. Wettbewerbsfähig bleibt nur, wer agiler in der Entwicklung von neuen Produkten und Dienstleistungen wird.

Behavior Driven Development (BDD) bietet eine Antwort auf die daraus resultierenden Herausforderungen in der Softwareentwicklung.

Daher haben wir 2009 das Softwareentwicklungswerkzeug “SpecFlow” als Open Source Produkt veröffentlicht, das sich seither zum de-facto Standard im .NET Bereich für BDD entwickelt hat.

SpecFlow wurde über 10 Millionen mal heruntergeladen, und hat aktuell über 30 Tausend aktive Nutzer im Monat. Das sind die beeindruckenden Zahlen nach über 10 Jahren Entwicklung dieser Idee.

Wir freuen uns mit Tricentis einen Partner gefunden zu haben, der das Potential von SpecFlow erkannt hat und es in die nächste Wachstumsphase führen wird.

Tricentis übernimmt SpecFlow sowie das 10-köpfige Team von TechTalk, das daran gearbeitet hat. Wir werden weiterhin eng mit Tricentis und der SpecFlow-Community zusammenarbeiten.

TechTalk bleibt eine eigenständige Beratungs- und Dienstleistungsfirma mit über 80 Mitarbeitern in den Bereichen agile Softwareentwicklung und eGovernment.

SpecFlow+, das kommerzielle Angebot von SpecFlow, und SpecMap, eine Azure DevOps-Erweiterung für User Story Mapping, werden ab sofort kostenlos angeboten.

Lesen Sie die Pressemitteilung von Tricentis (englisch) oder den Bericht auf TrendingTopics.

Rückfragen & Kontakt

Christian Hassa

Managing Partner TechTalk
 christian.hassa@techtalk.at
Vernetzen auf LinkedIn

PS: Das nächste Training zu SpecFlow bietet TechTalk im Mai an, die Anmeldung ist seit kurzem möglich.

Die Community-Konferenz zum Thema Agile – Eine Nachlese zur Agile Tour Vienna 2019

/in /von

Über 300 verkaufte Tickets, 30 Speaker in 25 Sessions, darunter auch drei Workshops, unzählige Kaffees, 200 Croissants, zwei tolle Sponsoren, ein Review Team aus 17 unterschiedlichen Firmen, so vielseitig war die diesjährige Agile Tour Vienna! Am 20. September war es soweit, nach Monaten der Vorbereitung endlich der Konferenztag.

Weitere Videoaufzeichnungen und Slides zu den Sessions findest Du in unserem Agile Tour Wiki.

Robert Finan führte uns durch den Konferenztag. Nach einer offiziellen Eröffnung und Danksagung an die Sponsoren und Organisatoren wurden die diesjährigen Experimente, ganz nach dem agilen Mindset, erklärt. Auch wir wollen im Zuge der Konferenz Neues ausprobieren und so die Agile Tour Vienna jedes Jahr verbessern. Die Experimente bauen auf dem Feedback der Teilnehmer auf, welches wir sowohl direkt auf der Konferenz entgegennehmen, als auch durch eine Umfrage nach der Konferenz.

Anschließend wurde unsere erste Keynote-Speakerin vorgestellt: Jenni Jepsen. Jenny sprach über Intent-Based Leadership und wie wir am Feedback erkennen können, stellt dies heutzutage ein wichtiges Thema dar. Wir haben Jenni’s Keynote aufgezeichnet, das Video findet ihr hier. Im März 2020 findet ein Training von Jenni Jepsen statt, das wir Dir sehr ans Herz legen können.

Wir fördern junge Talente

Der nächste Slot im Schedule war für unsere Young Talents reserviert. Schon das zweite Jahr in Folge ist dieses Format im Einsatz und hat sich auch heuer bewährt. Den Erfolg dieses Formats leiten wir unter anderem daraus ab, dass zwei der vier Young Talents von 2018  auch dieses Jahr einen Talk bei uns gehalten haben. Das freut uns natürlich besonders, merken wir dadurch doch, welchen Vorteil dieses Format für unsere Zielgruppe hat.

Besonders freut es uns, dass es dieses Jahr keine Absagen von Speakern gab. Somit konnten wir unseren Schedule wie geplant durchführen. Zum ersten Mal wurden unsere Sessions in vier Themen-Tracks unterteilt:

  • Successful Technical & Testing Practices,
  • Leadership & Organizational Development,
  • Amazing Products and
  • Reach Out – Agile Beyond IT.

In unserem Twitter-Feed wurden interessante Insights zu den Sessions geteilt!

Das erste Feedback von unseren Teilnehmern zu den Sessions zeigt, dass die Tracks sehr positiv wahrgenommen wurden. Wir konnten auch heuer wieder eine gute Qualität der einzelnen Sessions liefern. Ein besonderer Dank gilt hier unserem Review Team, das auch heuer wieder sensationelle Arbeit geleistet hat.

Wir fördern Austausch und Networking

Unser größtes Experiment dieses Jahr, der Meet-the-Speaker Slot, wurde von den Teilnehmern sehr unterschiedlich wahrgenommen. Wir werden das Feedback dazu besonders gut analysieren, um zu entscheiden, wie wir weiter damit umgehen wollen. Für uns persönlich war es eine Bereicherung der Konferenz, da wir dadurch den Austausch der Speaker mit den Teilnehmern forcieren sowie mehr Networking erreichen wollten und das haben wir bei einem Teil der Teilnehmer auch erreicht.

Meine persönlichen Highlights

Auch ich habe dieses Jahr ein paar Sessions besucht und möchte euch meine persönlichen zwei Highlights gerne genauer vorstellen:

Happiness leads to succes

Besonders spannend fand ich die Session “Wissenschaftlich belegt: WohlfühlChefs führen erfolgreicher!” von Ralph Miarka & Veronika Kotrba. Die Aussage zu Beginn „16 % der Österreicher sind nicht glücklich engagiert und motiviert im Beruf“ hat es auf den Punkt gebracht, wie wichtig es ist, dass es Personen in der Firma gibt, die sich um das Wohlbefinden der Kolleginnen aktiv kümmern. Denn “Happiness leads to success” wie Ralph und Veronika uns klarmachten. Diverse Motivationssysteme sowie Belohnungssysteme können hier unterstützen. Ein Beispiel war das SCARF Modell, bei dem wir soziale Gegebenheiten stärken. Weiters wurden vier Prinzipien der positiven Führung vorgestellt:

  1. positives Klima
  2. positive Beziehung
  3. positive Kommunikation
  4. positive Bedeutung

Folgende erste Schritte und schnell anwendbare Tipps wurden im Zuge der Session vorgestellt:

  • Erfolge feiern und Dankbarkeit zeigen
  • Individuelle Stärken nutzen und fördern
  • Unterbrechungsfreies Arbeiten ermöglichen
  • Ehrliches Interesse zeigen
  • Beitragsziele vereinbaren statt Leistungsziele
  • Erreichbares sichtbar machen

Struktur und Effizient mit dem passenden Meeting-Format

Ich habe noch einen Workshop besucht, den ich besonders spannend und interaktiv fand. Bei diesem Workshop ging es um zwei Meeting-Formate aus dem Holacracy Modell: Tactical Meeting und Governance Meeting.

Weiters habe ich diesmal auch an einem unserer Workshops teilgenommen: Gregor Karlinger & Bernhard Ibertsberger – “Warum die Meeting-Formate aus Holacracy für jedes (agile) Team hilfreich sind!”

Der Workshop war so aufgebaut, dass wir zuerst einen kurzen Theorieteil zu den beiden Formaten bekommen haben, um dann selbst die beiden Meetings auszuprobieren. Beim Tactical Meeting geht es darum, über offene Punkte zu informieren und ggfs. Infos einzuholen. Nach einem Meeting-Check-in wird dynamisch und gemeinsam die Agenda aufgebaut. Anschließend werden die Agenda-Punkte abgearbeitet: die Teilnehmer bringen die Punkte ein und man fokussiert sich auf die nächsten Schritte.

Der Prozess des Governance Meetings ist ähnlich, unterscheidet sich aber vor allem in der Abarbeitung der Agenda. Mit Hilfe der Moderation werden zuerst Vorschläge vorgestellt, um dann mittels klärenden Fragen der Teilnehmer diesen Vorschlag zu verstehen. Anschließend gibt es eine Reaktionsrunde und der Vorschlag kann angepasst werden. Danach werden mithilfe der “fünf Stufen der Einwände” potentielle Widerstände strukturiert bearbeitet. Ziel ist es diese zu integrieren, wenn es möglich ist, damit Widerstände der Teilnehmer minimiert werden.

Cocktails, Bier und Networking

Nach einem spannenden und lehrreichen Tag,  etlichen Sessions und drei Workshops, fanden wir uns schließlich alle gemeinsam nochmal zu der Abschluss-Keynote zusammen: Marcus Hammerberg, ein Agile Coach aus Schweden, erzählt uns seine persönliche Geschichte – wie er mit agilen Prinzipien ein Krankenhaus in Indonesien retten konnte. Diesen spannenden aber auch sehr intensiven Konferenztag, haben wir heuer wieder mit Cocktails und Bier abgerundet. Eine Cocktail Show auf der Bühne war der gelungene Übergang von Knowledge Sharing und Erfahrungsaustausch zum Networking.

Abschließend wollen wir uns noch einmal bei allen Mitwirkenden herzlich bedanken und freuen uns gemeinsam mit Euch auf die Agile Tour Vienna 2020!

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

Tickets

Zum Abschluss noch ein paar Schnappschüsse.