None

Agilität nach descript-Manier

Ein Mindset, das in keine Schublade passt!

Portraitbild des Autors Lilli Scholtes

Agiles Arbeiten, das ist doch nix Neues! Stimmt, nicht erst seit gestern steht Agilität im Projektmanagement für zeitgemäße Praxis und moderne Kommunikationsstrukturen. Auch in der Softwareentwicklung haben sich in den letzten Jahrzehnten, aufbauend auf dem agile manifesto, verschiedene Mindsets wie u.a. Scrum, Kanban oder XP durchgesetzt, welche Entwicklungsprozesse transparenter, anpassungsfähiger und fortschrittlicher machen sollen.

Bei allen Konzepten geht es im Wesentlichen darum, die Planungsphase auf ein Mindestmaß zu reduzieren, um so früh wie möglich zu ausführbarer Software zu gelangen. Daraus resultieren zum einen ein geringeres Risiko für Fehlentwicklungen und zum anderen ein größeres Potenzial, neue Kundenwünsche zu berücksichtigen. Gearbeitet wird iterativ und inkrementell in selbstorganisierten Teams. Soweit die Theorie.

Was mich aber wirklich interessiert (und dich wahrscheinlich auch): Was bedeutet Agilität für die Mitarbeitenden und Geschäftsführenden von descript? Nach welchem Mindset agieren wir und wie sieht die konkrete Umsetzung aus? Und vor allem, wodurch macht sich das in der täglichen, persönlichen Arbeit bemerkbar? Also habe ich das Gespräch mit meinen neuen Kolleginnen und Kollegen gesucht, fleißig mitgeschrieben und die Antworten in diesem Blogpost zusammengefasst.

Neue Methoden für ein größeres Team

Angefangen hat descript vor 17 Jahren als ein kleines Drei-Mann-Unternehmen, in dem jeder genau wusste, woran der andere gerade arbeitet. Um diese Transparenz auch in einem stetig wachsenden Team von mittlerweile 16 Mitarbeitenden aufrecht zu erhalten, arbeiten wir in kurzen, ein- bis zweiwöchigen Entwicklungszyklen, mit regelmäßigen Möglichkeiten zum Austausch über den aktuellen Arbeitsstand. Wir orientieren uns an dem bisweilen eher unbekannten Konzept Shape-Up, bei dem ein komplexes Thema auf wesentliche Aspekte heruntergebrochen wird, bevor es dem Entwicklungsteam für die eigenverantwortliche Umsetzung übergeben wird.

Abbildung des iterativen Entwicklungs-Ansatz bei descript

Da gleichzeitig alle Beteiligten über alle Anforderungen informiert sind und die zu bearbeitenden Aufgaben gemeinsam herauskristallisiert werden, vermeiden wir ein „Nebeneinander-her-entwickeln“. In der Pädagogik bezeichnet man diese Vorgehensweise als analytisch-synthetisch – wir zergliedern das große Gesamtthema in überschaubare, zu bearbeitende Teilthemen, um sie später wieder zusammenzusetzen.

Mehr Kommunikation für mehr Ruhe

Ritualisierte Gesprächsrunden wie Dailys, wöchentliche Scopings und Sprint-Reviews verkleinern unsere Kommunikationsintervalle untereinander, sodass es insgesamt weniger Unklarheiten und dafür eine verstärkte Zielgerichtetheit gibt. Den Rahmen für mündliche Abstimmungen bilden festgelegte Strukturen, die den zeitlichen und organisatorischen Ablauf, sowie die zugehörige Dokumentation steuern.

Dekoratives Bild mit zwei Sprechblasen

Unsere Erfahrung hat gezeigt, dass unsere Meetings durch diese Steuerung und Regelmäßigkeit, kontinuierlich effektiver werden. Genau das, was wir auch Kunden mit unserer Software ermöglichen wollen, nämlich mehr Fokus und Einfachheit, erreichen wir damit auch für unser Team. Denn wenn alle wissen was zu tun ist, sorgt das für einen insgesamt ruhigeren und reibungslosen Arbeitsprozess.

Probieren geht über codieren

Wir wollen nicht irgendetwas machen, was am Ende nicht zu uns passt – soviel steht fest! Deshalb probieren wir immer wieder neue Methoden aus, schauen, wie die Umsetzung läuft und entscheiden dann gemeinsam, inwieweit sich diese für unsere persönliche Arbeitsweise eignen und welcher Mehrwert aus ihrer Anwendung resultiert. Die Vorteile von Shape-Up kommen insbesondere in der Entwicklung unseres neuesten Produktes Mataono zum Ausdruck, bei der wir ganzheitlich agil arbeiten.

Durch das Aufteilen einer komplexen Beratungssoftware in ihre individuellen Teilanwendungen, erzeugen wir einen Workflow, der für das gesamte Team leistbar und deshalb motivierend ist. Gleichzeitig profitieren alle von einer besseren Übersichtlichkeit der anstehenden Entwicklungsaufgaben, einer leichteren Planbarkeit, bei der das Ergebnis – nicht der Umfang – feststeht und dem ständigen Austausch zwischen den Beteiligten.

Die Idee hinter Mataono Icon For Arrow-right

Wir wachsen mit unseren Aufgaben

Es ist uns wichtig, dass das gesamte Team an unseren Ideen mitwirken kann, weshalb alle Entwicklerinnen und Entwickler, unabhängig von ihrer beruflichen Erfahrung, in den Scoping-Prozess eingebunden werden. Gemeinsam werden Aufgaben und deren personelle Verteilung festgelegt, sowie kurzfristige Zielstellungen entwickelt. Daraus resultieren für unsere gesamte Crew große Gestaltungs- und Handlungsfreiräume, sowie vielfältige Möglichkeiten, Verantwortung zu übernehmen.

Dieses Selbstverständnis betrifft nicht nur den Bereich der Softwareentwicklung, sondern alle Arbeitsbereiche bei descript. Seit gut einem Monat bin ich als Marketingexpertin an Bord und kann mit viel Eigenverantwortung und Kreativität, meine Gedanken in die Tat umsetzen. Dabei erhalte ich begleitend genau die Unterstützung und Rückmeldung, die ich brauche, um mich weiterzuentwickeln.

Dekoratives Bild mit einem starken Mädchen
Komm' mit an Bord Icon For Arrow-right

Wie mein Bewerbungsprozess bei descript abgelaufen ist und unser Recruiting für den Bereich Softwareentwicklung im Einzelnen aussieht, erfährst du in unserem nächsten Blogpost!


Teile diesen Beitrag, wenn er dir gefallen hat: Teilen:

Wer hat's geschrieben? Lilli Scholtes
Portraitbild des Autors Lilli Scholtes
Lilli war bis Ende 2021 Marketing-Expertin bei descript. Sie sammelte unsere verrückten Ideen, brachte ihre eigenen Vorstellungen mit an den Tisch und machte aus allem eine runde Sache.
Lass uns im Gespräch bleiben Du findest den Beitrag spannend?

Das Thema des Beitrages interessiert dich? Du möchtest dich darüber austauschen, deine Meinung kundtun oder zukünftig mehr von uns lesen? Dann folge uns auf unseren Kanälen bei Instagram und LinkedIn.