Agile Development at drunomics – Scrum, DevOps und wiederholbare Delivery in echten Kundenprojekten

Einleitung: Was wir bei „Agile Development at drunomics“ gelernt haben

In „Agile Development at drunomics“ zeigte Jeremy Chinquist (drunomics GmbH) aus der Praxis, wie ein Agenturteam Agile, Scrum und DevOps so miteinander verknüpft, dass reale Kundenerwartungen erfüllt werden – von großen Medienportalen bis zu kleineren Support-Mandaten. Als Projektmanager und Scrum Master beschreibt er, wie drunomics in Wien und Linz komplexe Drupal-Projekte mit einem klaren Fokus auf wiederholbare Prozesse, produktionsnahe Qualitätssicherung und konsequente Stakeholder-Kommunikation steuert.

Die Kernthemen der Session:

• Agile Kernprinzipien, die tatsächlich gelebt werden: häufige Lieferungen, flexible Reaktion auf Änderungen, konsequentes Feedback.
• Das Zusammenspiel von Agile und DevOps: Flow, Feedback, kontinuierliches Lernen und Experimentieren.
• Scrum in der Praxis: sinnvolle Sprintlängen, Definition of Ready/Done, Rollen, Backlog-Disziplin.
• Operative Exzellenz: Ticketing-Standards, Templates, eine „Single Source of Truth“, Git-Branch-Strategie und GitHub Actions für CI.
• Kultur und Organisation: Verantwortung des Product Owners, Proxy-Rolle, blameless Retrospektiven und Wissensaufbau.

Wir halten die wichtigsten technischen und methodischen Muster fest – so, wie Jeremy sie aus laufenden Projekten kennt. Ohne Hype, ohne Buzzwords: nur die Dinge, die Teams zuverlässig liefern lassen.

Kontext: drunomics, Projektlandschaft und typische Anforderungen

drunomics GmbH ist ein Drupal-Entwicklungspartner, der für Unternehmen Webseiten entwickelt und berät. Jeremy betont die Bandbreite: große, laufende Projekte mit wöchentlichen Inkrementen, mittlere Setups und kleinere Kunden mit Fokus auf laufenden Support. Branchenreichweite: Medien und Publishing besonders stark, dazu Bildung, Autoindustrie, Finanz, Immobilien und Crowdfunding.

Viele Vorhaben haben maßgeschneiderte Workflows als Kern. Genau dort entscheidet sich, ob Agile wirklich trägt – wenn Stakeholder regelmäßig liefern wollen, Anforderungen sich verschieben und Teams simultan Frontend/Backend, Integrationen und Betrieb koordiniert bekommen.

Agile Kernelemente: Häufig liefern, Änderungen willkommen heißen, kommunizieren

Jeremy verankert die Praxis klar in den Grundgedanken des Agile-Manifestos:

• Häufig nutzbare Features liefern: Continuous Delivery/Deployment/Integration sind Mittel, um sichtbar voranzukommen – auch wenn Features zunächst „versteckt“ oder nur intern zugänglich sind.
• Flexibel auf geänderte Anforderungen reagieren: In jedem Sprint die Prioritäten neu ordnen und Stakeholder-Bedarf aufnehmen.
• Kommunikation als Schlüssel: Regelmäßiges, konsequentes Feedback von Stakeholdern ist unverhandelbar, weil diese täglich mit dem System arbeiten.
• Motivierte, lernende Teams: Selbstreflexion und kontinuierliche Verbesserung sind kein Luxus, sondern der Weg zu wertvollen Produkten.

Dabei macht Jeremy einen realistischen Punkt: Agile wird von Stakeholdern unterschiedlich verstanden. Wer mit falschen Erwartungen startet (z. B. „Agile heißt: Deadlines sind egal“), muss früh abgeholt werden. Die Erwartungstransparenz ist Teil der Methodik – sonst entstehen Friktionen, die sich später schwerer lösen lassen.

DevOps-Kompass: Flow, Feedback, kontinuierliches Lernen

Agile und DevOps verstärken sich gegenseitig. Jeremy knüpft an die drei DevOps-Prinzipien an, die (u. a. auch im „Phoenix Project“) verdichtet sind:

• Prinzipien des Flows: Kontinuierlich liefern und die Liefergeschwindigkeit steigern – Prozesse schärfen, Verschwendung minimieren, Engpässe erkennen. Das deckt sich mit kurzen, wertorientierten Inkrementen im agilen Arbeiten.
• Prinzipien des Feedbacks: Laufendes, ehrliches Feedback – technisch wie fachlich. Für Entwickler:innen bedeutet das, Lob und Kritik gleichermaßen anzunehmen, um die richtigen Produkte zu bauen.
• Kontinuierliches Lernen und Experimentieren: Selbstorganisierte Teams, Retrospektiven, regelmäßige Reviews und die Bereitschaft, Wissen explizit zu machen.

In dieser Brücke liegt die operative Kraft: Agile setzt den Takt und die Stakeholderausrichtung, DevOps liefert die Fließfähigkeit, die nötige Telemetrie und die Wiederholbarkeit.

Scrum in der Praxis: Rollen, Zyklen, Backlog, Events

Jeremy zeichnet das bekannte Scrum-Bild nach – und fokussiert auf das, was in Projekten das Ergebnis wirklich beeinflusst:

• Rollen: Product Owner, Scrum Master, Entwicklungsteam; Stakeholder validieren Ergebnisse.
• Backlog: Der Product Owner verantwortet die Priorisierung. Das Team committet sich auf Umsetzungsumfänge (User Stories) je Sprint.
• Events: Planung, Umsetzung, Review und Retrospektive pro Sprintzyklus – mit einer für Team und Kunde passenden Kadenz.

Die richtige Sprintlänge finden

Die Sprintdauer ist kein Dogma, sondern eine projektspezifische Entscheidung:

• Große Teams: drei Wochen haben sich bewährt – zwei Wochen sind zu kurz, und längere Zyklen blähen die Pakete zu stark auf.
• Kleine Teams: vier Wochen sind praktischer – ein monatlicher Takt für Planung, Review, Retrospektive ist übersichtlich, drei Wochen sind hier oft zu knapp.

Die Lehre: Sprintlängen früh festlegen, regelmäßig validieren und an die Teamgröße sowie Meeting-Kadenz anpassen.

Definition of Ready (DoR) und Definition of Done (DoD)

Zwei Definitionen, die Sprints tragen – oder scheitern lassen:

• Definition of Ready: Ist die User Story reif für die Umsetzung? Fehlt Wesentliches, muss sie zurückgestellt werden. Das Team will liefern, nicht blockiert sein.
• Definition of Done: „Code fertig“ reicht nicht. Erst prüft der Product Owner und akzeptiert. Erst dann sehen Stakeholder das Inkrement. Done ist eine fachlich/technische Abnahme, nicht nur ein Merge.

Teamzuschnitt: Skills dynamisch ausbalancieren

Scrum ist kein starres Staffing. Wenn ein Sprint Frontend-lastig wird (z. B. API-Integrationen, UI-Schichten), müssen ausreichend Frontend-Kapazitäten da sein – notfalls temporär verschoben zwischen Frontend/Backend. Wichtig ist, die Werkzeuge und das Setup bereitzustellen, damit das Team liefern kann.

Outcome-orientiertheit zählt: Wer regelmäßig committen und dann auch liefern kann, baut Vertrauen bei Stakeholdern auf – das ist eine der stärksten Wirkungen konsistenter Sprints.

Kommunikations- und Arbeitsgrundlagen: Single Source of Truth, Stories und Templates

Ticketing: Jira oder YouTrack, sauber formulierte Nutzerstories

drunomics arbeitet mit etablierten Ticketingsystemen (Jira oder YouTrack). Entscheidend ist nicht das Tool, sondern die Qualität der Nutzerstories (User Stories). Klar formuliert, verständlich für Stakeholder und Entwickler:innen – und bei Bedarf vorab zur Validierung an Stakeholder geschickt.

Keine Feature-Steuerung per E-Mail

E-Mail ist kein tragfähiger Projektkanal für Anforderungen. Jeremy nennt die bekannten Probleme: Dinge werden übersehen, Versionen und Stände sind unklar. Stattdessen braucht es einen „Single Point of Truth“. Confluence hat sich dafür bei ihm bewährt; andere Werkzeuge gehen ebenso – entscheidend ist die eine verlässliche Quelle.

Workflows und Checklisten für wiederholbare Deployments

Für wiederkehrende Prozesse (Deployment, Releases, Migrationen) setzt das Team auf klare Workflows und Checklisten. Vorteile:

• Man muss nicht jedes Mal neu nachdenken – der Prozess führt.
• Abweichungen werden transparent, Probleme lassen sich im Nachgang gezielt analysieren.
• Post-Deploy-Reviews werden datenbasiert und fokussiert.

Continuous Integration: Branch-basiert, pipelines-first, GitHub Actions

Continuous Integration ist bei drunomics Standard. Jedes Projekt verfügt über Build-Pipelines, die sichtbar machen, wo etwas bricht – oder zuverlässig durchläuft. Jeremy beschreibt das Setup so:

• Für neue Features entsteht je ein Git-Branch.
• Dieser Branch durchläuft die Pipeline – mit mehreren Schritten und Checks.
• Ergebnis ist eine reduzierte, aber aussagekräftige Kopie der Website, um Feature-Verhalten zu testen.
• Der Product Owner kann auf dieser Basis prüfen und freigeben.

Technisch nutzt drunomics häufig GitHub Actions. Der Punkt ist nicht das spezifische Tool, sondern die Reproduzierbarkeit: Ein automatisierbarer, beobachtbarer Weg vom Commit bis zum testbaren Artefakt.

Ticket-Management: Epics, Stories, Tasks, Abhängigkeiten, Zustände

Jeremy legt großen Wert auf Stringenz in der Ticketstruktur – weil sie den Output bestimmt.

Strukturelle Ebenen

• Epics: in sich schließbare Features auf hohem Level, die geliefert und geschlossen werden können.
• User Stories: fachliche Einheiten (z. B. „Als Redakteur möchte ich einen Artikel aktualisieren und bearbeiten …“), die Stakeholder-Mehrwert ausdrücken.
• Tasks: technische Zerlegung der Story für Backend, Frontend, Test.

Die Lieferung erfolgt auf Story-Ebene: Das Team liefert an den Product Owner, der akzeptiert, danach gehen Stories an die Stakeholder.

Abhängigkeiten managen – Blocker früh erkennen

Wenn eine Story von einer anderen Funktion abhängt, die noch nicht existiert, ist sie im Sprint fehl am Platz. Aufgabe des Product Owners: Abhängigkeiten prüfen, Blocker transparent machen, ggf. Tickets umschneiden, damit etwas Sinnvolles umgesetzt werden kann. Das Ziel ist, commitbare Pakete zu bilden, die im Sprint tatsächlich fertig werden können.

Ticket-Templates

Standardisierte Ticket-Templates reduzieren Reibung. Stakeholder und Entwickler:innen wissen, welche Informationen wo stehen, und erkennen schneller, ob etwas passt. So werden Missverständnisse vermieden und die Umsetzung beschleunigt.

Zustände und „Next Step“-Klarheit

Ein häufiges Anti-Pattern kennt jede:r: eine Kommentarflut (Kommentar #79 …) und niemand weiß, was als Nächstes zu tun ist. Jeremy pocht darauf, die Ticketbeschreibung aktuell zu halten und Zustände sowie Assignees klar zu pflegen. Leitfrage: „Was ist der nächste konkrete Schritt?“ – und wenn er klar ist, gehört er in das Ticket, nicht nur in die Kommentare.

Rollen und Verantwortlichkeit: Product Owner und PO-Proxy

Der Product Owner ist aus Jeremys Sicht die entscheidende Rolle für Agile-Delivery:

• Verantwortet das Backlog und die Priorisierung.
• Prüft und akzeptiert Ergebnisse, bevor Stakeholder sie sehen.
• Steht sichtbar hinter den gelieferten Inkrementen.
• Ist fachlich nah am Kunden, um Entscheidungen belastbar zu treffen.

drunomics arbeitet zusätzlich mit einer Product-Owner-Proxy-Rolle – jemandem nahe am Entwicklungsteam (häufig Jeremy selbst), der bei Abwesenheit einspringt, in engem Austausch mit dem PO steht und Entscheidungen absichert. Das ist nicht „reines“ Scrum, aber praktisch und human: Menschen haben Urlaub, werden krank. Die Proxy-Rolle hält den Fluss aufrecht.

Interpretationsspielraum vs. Validierung: Wann Entwickler:innen vorgehen – und wann nicht

Manchmal ist es sinnvoll, den Bedarf eines Stakeholders zu antizipieren und in der Storybeschreibung zu präzisieren. Aber: Bei Unklarheit ist Validierung Pflicht. Erst die Formulierung nach bestem Verständnis schreiben, dann die Freigabe des Stakeholders einholen – bevor Implementierung startet. Denn nichts ist teurer als zwei Wochen Entwicklung in die falsche Richtung.

Kulturfragen: Balance statt Dogmatismus, blameless Retros, explizites Wissen

Jeremy macht keinen Hehl daraus: 100 % Scrum erfüllt kein Projekt. Es braucht eine vernünftige Balance – so viel Methodik wie nötig, so viel Pragmatismus wie hilfreich.

Wichtig sind die dazu passenden kulturellen Praktiken:

• Blameless Postmortems/Retrospektiven: Probleme offen ansprechen, ohne Schuldzuweisungen. Persönliches Coaching kann separat stattfinden; die Teamrunde dient der Ursachenklärung und Verbesserung.
• Moderation durch die/den Scrum Master: Wenn eine Diskussion kippt, ist Moderation gefragt – „Stop, neu sortieren, dann konstruktiv weiter“.
• Tacit nach explicit: Implizites Wissen in dokumentiertes, wiederverwendbares Wissen wandeln – z. B. durch Wissensbasen. Jeremy nennt die wiederkehrende Integration von Solr-Suche als Beispiel, die so reproduzierbar wurde.

Wiederholbarkeit als Qualitätsmerkmal: Was Delivery verlässlich macht

Ein roter Faden durch die Session ist Wiederholbarkeit:

• Standardisierte Sprintlängen, die zum Team passen.
• DoR/DoD, die gelebt werden – insbesondere die Gatekeeper-Funktion des Product Owners.
• CI-Pipelines, die Branches früh prüfen und Produkt-Owner-Tests auf einer realitätsnahen Umgebung ermöglichen.
• Ticket-Disziplin: Templates, Abhängigkeiten, Zustände, „Next Step“.
• Single Source of Truth statt E-Mail.
• Workflows/Checklisten für Builds und Deployments.
• Blameless Retros, die echte Verbesserungen erzeugen.

Die Summe ergibt Vertrauen: Stakeholder sehen, dass Commitments eingehalten werden. Das Team gewinnt Stabilität, weil es weiß, wie Arbeitspakete „fertig“ werden.

Konkrete Takeaways für Engineering-Teams

• Sprintlänge bewusst wählen: Für große Teams eher drei Wochen; für kleine Teams vier Wochen. Zwei Wochen sind in Jeremys Erfahrung zu kurz.
• Definition of Ready/Done schärfen: Stories nur dann in den Sprint ziehen, wenn sie umsetzbar sind; „Done“ erst nach Product-Owner-Akzeptanz.
• Product Owner stärken: PO als fachlicher Gatekeeper vor Stakeholdern; Proxy-Rolle als operatives Backup etablieren.
• CI als Standard: Pro Feature-Branch Pipeline laufen lassen, bis eine testbare Umgebung entsteht; GitHub Actions oder vergleichbare Tools nutzen.
• Ticketing standardisieren: Epics/Stories/Tasks sauber trennen; Abhängigkeiten früh klären; Templates pflegen; Zustände/Assignees aktuell halten.
• Wissensmanagement und Dokumentation: Eine Quelle der Wahrheit (z. B. Confluence) und explizite Checklisten/Workflows etablieren.
• Kommunikation fokussieren: Feedback der Stakeholder aktiv einholen; E-Mail nicht als Anforderungsmedium verwenden.
• Kultur aktiv gestalten: Blameless Retrospektiven, Moderation durch Scrum Master, kontinuierliches Lernen und Experimentieren fördern.

Fazit: Agile und DevOps – gemeinsam wirksam, wenn das Handwerk stimmt

„Agile Development at drunomics“ zeigt eine nüchterne, robuste Praxis: Agile Prinzipien werden mit DevOps-Mechaniken untrennbar verknüpft. Die Methodik bleibt kein Selbstzweck. Entscheidend sind die operativen Details – von der Sprintlänge über DoR/DoD, Ticketqualität und CI bis zur Rolle des Product Owners. Dort, wo Prozesse wiederholbar sind und Feedbackzyklen kurz bleiben, entstehen verlässliche Lieferungen. Genau so baut drunomics Vertrauen bei Stakeholdern auf – Sprint für Sprint, Inkrement für Inkrement.

• 

  

  mossbo Cloud CMS Ecosystem

  Wolfgang Ziegler von drunomics gibt in seinem devjobs.at TechTalk einen Überblick über die grundlegenden Funktionen von mossbo und welche Benefits es im Vergleich zu anderen CMS' gibt.

  Jetzt ansehen
• 

  

  Professionelle Web Entwicklung aus Österreich

  Oliver Berndt von drunomics zeigt in seinem devjobs.at TechTalk die Kernkompetenzen von dem Unternehmen und wie sie mit Drupal arbeiten.

  Jetzt ansehen
• 

  

  Security- und Risiko-Management

  Jeremy Chinquist von drunomics erzählt in seinem devjobs.at Interview darüber, wie das Unternehmen mit Security- und Risiko-Management umgeht und welche Standards eingehalten werden.

  Jetzt ansehen
• 

  

  Web Accessibility

  Jeremy Chinquist von drunomics gibt im Interview einen Überblick über die wesentlichen Eckpunkte von Accessibility im Web und dem EAA.

  Jetzt ansehen

• 

  

  Sinduri Guntupalli, Product Manager bei drunomics

  Sinduri Guntupalli von drunomics spricht im Interview über ihren technischen Background und das Besondere an der Arbeit mit Drupal.

  Jetzt ansehen