Agile Development at drunomics: Scrum, DevOps, and Repeatable Delivery in Real Client Work

Introduction: What “Agile Development at drunomics” Reveals

In “Agile Development at drunomics,” Jeremy Chinquist (drunomics GmbH) cuts through the noise and shows how an agency team blends Agile, Scrum, and DevOps to meet real stakeholder expectations across large-scale media builds, education platforms, finance, real estate, automotive, crowdfunding, and more. As a project manager and Scrum Master, he explains how drunomics in Vienna and Linz delivers complex Drupal projects with a clear bias toward repeatable processes, production-like testing, and disciplined stakeholder communication.

Key themes from the session:

• Core Agile behaviors actually practiced: deliver usable features often, embrace changing requirements, and make feedback a habit.
• The bridge between Agile and DevOps: flow, feedback, and continuous learning/experimentation.
• Scrum in practice: picking the right sprint length, sharpening Definition of Ready/Done, roles, backlog discipline.
• Operational excellence: ticket standards, templates, a single source of truth, branch-based development, and CI with GitHub Actions.
• Culture and organization: Product Owner accountability, the PO-proxy pattern, blameless retrospectives, and building explicit knowledge.

We capture the technical and process patterns exactly as Jeremy runs them in ongoing work—no buzzwords, just the habits that help teams ship reliably.

Context: drunomics, project mix, and typical demands

drunomics GmbH is a Drupal development partner delivering websites and consulting. Jeremy highlights the range: large, ongoing projects with weekly output, mid-sized builds, and smaller clients with ongoing support needs. Media and publishing feature prominently, with education, auto, finance, real estate, and crowdfunding in the portfolio too.

Custom workflows are a recurring theme. This is where Agile either holds or crumbles—when stakeholders want regular delivery, requirements change mid-flight, and teams must coordinate frontend/backend, integrations, and operations in parallel.

Agile fundamentals: ship often, embrace change, communicate

Jeremy anchors the practice in the Agile Manifesto’s essentials:

• Deliver usable features often: continuous delivery/deployment/integration keeps momentum visible—even when features start “hidden” or internal-only for testing.
• Be flexible to changing requirements: reorder priorities each sprint and respond to stakeholder needs.
• Communication is non-negotiable: regular stakeholder feedback is crucial because they use the system every day.
• Motivated, learning teams: active reflection and self-improvement are how valuable products get built.

Jeremy stresses a practical point: clients bring preconceptions about Agile. If someone equates “Agile” with loose deadlines, correct that fast. Expectation alignment is a core part of the method; otherwise you bake in friction that’s harder to resolve later.

DevOps as a force multiplier: flow, feedback, and learning

Agile and DevOps reinforce one another. Jeremy maps his approach to three DevOps principles (as also highlighted in the Phoenix Project):

• Principles of flow: continuously deliver and accelerate delivery—sharpen processes, reduce friction, identify bottlenecks. This aligns naturally with short, value-focused increments.
• Principles of feedback: consistent, candid feedback—both technical and business-facing. Developers must be willing to receive criticism and praise; it’s how you build the right thing.
• Continual learning and experimentation: self-organizing teams, regular reviews, retrospectives, and making improvements stick.

This bridge is where operational leverage lives: Agile sets cadence and stakeholder focus, DevOps provides the flow, telemetry, and repeatability.

Scrum in practice: roles, cycles, backlog, and events

Jeremy revisits the canonical Scrum picture and emphasizes what truly moves outcomes in projects:

• Roles: Product Owner, Scrum Master, development team; stakeholders validate results.
• Backlog: Product Owner owns prioritization. The team commits to story-level work per sprint.
• Events: planning, implementation, review, and retrospective per sprint—in a cadence that fits the team and client.

Pick a sprint length that fits the team

Sprint duration is a design choice, not a dogma:

• Large teams: three weeks work well—two weeks are too short; longer cycles grow batches too large.
• Small teams: four weeks are practical—monthly planning/review/retro is tidy; three weeks are often too tight here.

The lesson: set iteration length deliberately, revisit it, and align it with team size and meeting cadence.

Definition of Ready and Definition of Done

Two definitions either support a sprint—or sink it:

• Definition of Ready: is the story truly ready to be developed? If key pieces are missing, it should be deferred. The team wants to deliver, not stall.
• Definition of Done: “coding finished” is not done. The Product Owner must review and accept first. Only then do stakeholders see it. Done is a functional/technical acceptance, not just a merge.

Team composition: dynamically balance skills

Scrum isn’t rigid staffing. If a sprint becomes frontend-heavy (e.g., API consumption, UI layers), ensure sufficient frontend capacity—even if it means shifting the balance between frontend and backend for a sprint. What matters is giving the team the tools and setup to deliver.

The effect is trust: committing and then delivering each sprint builds stakeholder confidence. That consistency is one of Agile’s strongest signals.

Communication and working agreements: one source of truth, stories, templates

Ticketing: Jira or YouTrack, well-formed user stories

The team uses established systems (Jira or YouTrack). The tool isn’t the point; story quality is. Stories must be clearly written and understandable to both stakeholders and engineers—and sent to stakeholders for validation when needed.

Don’t manage features by email

Email is a poor medium for evolving requirements. People miss messages, versions drift, and there’s no stable reference. Use a single point of truth instead. Jeremy has had good experience with Confluence; other tools work too—the key is having one reliable source.

Workflows and checklists for repeatable deployments

For recurring processes (deployments, releases, migrations), the team leans on explicit workflows and checklists. Benefits:

• You don’t have to reinvent execution every time.
• Deviations are visible; problems can be targeted in post-deploy reviews.
• The whole delivery chain becomes safer and more predictable.

Continuous Integration: branch-based pipelines with GitHub Actions

Continuous Integration is a first-class practice at drunomics. Every project has build pipelines to make failures visible—and success boring. Jeremy’s outline:

• Each feature starts on its own Git branch.
• That branch runs through the pipeline with multiple checks.
• The output is a reduced but realistic copy of the website to test behavior.
• The Product Owner can then evaluate and accept.

Technically, the team often uses GitHub Actions. The point isn’t the specific tool but repeatability: an automated, observable path from commit to a testable artifact.

Ticket management: epics, stories, tasks, dependencies, states

Jeremy insists on discipline in the ticket structure—because it drives outcomes.

Structural levels

• Epics: high-level features that can be delivered and closed.
• User stories: business-facing increments (e.g., “As an editor I want to update and edit an article …”).
• Tasks: the technical breakdown for backend, frontend, and testing.

Delivery happens at the story level: the team delivers to the Product Owner; once accepted, stories go to stakeholders for testing.

Manage dependencies—flag blockers early

If a story depends on something that doesn’t exist yet, it doesn’t belong in the sprint. The Product Owner must vet dependencies, expose blockers, or reshape tickets so that useful work can be done. The goal is to form sprintable packages that can be finished.

Ticket templates

Templates reduce friction. When stakeholders and developers know the structure and content expected, they can quickly spot mismatches and reduce ambiguity. That speeds up implementation and improves quality.

States and “next step” clarity

A common anti-pattern: a comment thread dozens of entries long, yet nobody knows the next action. Jeremy pushes teams to keep the ticket description current and maintain assignees and states clearly. Guiding question: “What’s the next concrete step?”—and if it’s known, it belongs in the ticket, not just in comments.

Roles and accountability: Product Owner and the PO proxy

For Jeremy, the Product Owner is pivotal to Agile delivery:

• Owns the backlog and prioritization.
• Reviews and accepts results before stakeholders see them.
• Visibly stands behind delivered increments.
• Sits close to the client to make sound decisions.

drunomics complements this with a Product Owner proxy—someone close to the development team (often Jeremy himself) who can step in during absences and maintain tight coordination with the PO. It isn’t “pure” Scrum, but it’s practical and human: people take vacations and get sick. The proxy keeps flow intact.

Interpretation vs. validation: when to anticipate, when to confirm

Sometimes it’s sensible to anticipate what a stakeholder wants and refine a story accordingly. But: if there’s any doubt, validate first. Write your best understanding, then get stakeholder approval before building. Nothing is costlier than two weeks of development in the wrong direction.

Culture: balance over dogma, blameless retros, explicit knowledge

Jeremy is candid: no project follows Scrum 100%. You need a reasonable balance—enough method to keep you honest, enough pragmatism to deliver.

Supporting cultural practices include:

• Blameless postmortems/retrospectives: talk openly about problems without blame. Personal coaching can happen separately; the team setting is for root causes and improvements.
• Scrum Master moderation: when a discussion derails, call a timeout—reframe and continue constructively.
• Turn tacit into explicit knowledge: document repeatable patterns and build a knowledge base. Jeremy cites repeated Solr search integrations as an example that became reproducible through this approach.

Repeatability as a quality bar: what makes delivery trustworthy

A thread through the session is repeatability:

• Standardized sprint lengths that fit the team.
• Lived DoR/DoD—especially the Product Owner as gatekeeper before stakeholders.
• CI pipelines that test feature branches early and enable Product Owner testing on realistic environments.
• Ticket discipline: templates, dependency checks, clean states, and an explicit “next step.”
• A single source of truth instead of email sprawl.
• Workflows and checklists for builds and deployments.
• Blameless retros that produce real improvements.

Taken together, this builds trust: stakeholders see commitments honored, and teams gain stability by knowing how work gets to “done.”

Practical takeaways for engineering teams

• Choose sprint length deliberately: three weeks for larger teams; four weeks for smaller teams. Two weeks are often too short in Jeremy’s experience.
• Sharpen Definition of Ready/Done: only pull sprint-ready stories; “done” after Product Owner acceptance.
• Empower the Product Owner: make the PO the functional gatekeeper before stakeholder exposure; add a PO-proxy as an operational backup.
• Make CI standard: run pipelines per feature branch until you have a testable environment; use GitHub Actions or equivalent tooling.
• Standardize ticketing: separate epics/stories/tasks; surface dependencies early; maintain templates; keep states/assignees current.
• Invest in documentation: one source of truth (e.g., Confluence) and explicit checklists/workflows.
• Focus communication: actively seek stakeholder feedback; do not use email to drive requirements.
• Shape culture intentionally: blameless retrospectives, strong facilitation by the Scrum Master, and continuous learning/experimentation.

Conclusion: Agile and DevOps—effective together when the craft is solid

“Agile Development at drunomics” demonstrates a grounded, reliable practice: Agile principles tightly coupled with DevOps mechanics. The method isn’t an end in itself. The operational details matter—from sprint length, DoR/DoD, ticket quality, and CI to the Product Owner’s gatekeeping. Where processes are repeatable and feedback loops are short, delivery becomes trustworthy. That’s how drunomics builds stakeholder confidence—sprint by sprint, increment by increment.

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now
• 

  

  Web Accessibility

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

  Watch now
• 

  

  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.

  Watch now

• 

  

  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.

  Watch now