Disciplined Agile as a Toolkit: Matching the Way of Working to the Work

The projects I build at VEAI LAB do not have one shared shape.

ParkinSync is a serverless data pipeline connecting structured paper care logs, human verification, AWS services, environmental data, and analysis. CareReady is a browser-based checklist that must make sense to families while also giving facilities a controlled way to publish their own templates. A static marketing site has a different risk profile again: DNS, certificates, cache behaviour, and a deployment path that should not depend on a person remembering a manual step.

Trying to run all of that with the same ceremony would be a category error.

That is why I find Disciplined Agile (DA) useful. Not as a badge I claim for VEAI LAB, and not as a replacement for sound engineering. I use its core idea — choose a fit-for-purpose way of working from a guided set of options — as a prompt before I reach for a process.

The question is not “Which framework are we?”

The more useful questions are:

• What problem are we trying to solve now?
• What kind of uncertainty is present: product, technical, operational, or stakeholder?
• What cannot safely be automated or deferred?
• Who has to understand or support the result after release?
• What is the lightest process that gives us enough evidence to proceed?

DA formalises this style of reasoning through process goals and context-sensitive choices. The exact terminology matters less to me than the discipline behind it: make the choice explicit, explain why it fits, and revisit it when the context changes.

One lab, different delivery shapes

ParkinSync needs a controlled data path. OCR is useful, but it is not trusted to silently populate care observations. The design retains a human verification point before ingestion. That is closer to a quality gate than a fully automated continuous-flow process, and it is appropriate because the cost of a convincing but wrong row can travel into later analysis.

CareReady needs rapid learning in a different place. The technical pieces — IndexedDB persistence, a service worker, a share-code redeem endpoint, a Cognito-protected staff API — can be tested in code. But the real uncertainty is also social and operational: does a facility template fit how staff prepare information, and does the resulting family flow reduce effort rather than create another account to manage? The next step is not merely “build more.” It is to validate the workflow with the people around it.

For the VEAI LAB site, I chose a small, inspectable system: Astro for static generation, S3 and CloudFront for delivery, and GitHub Actions with OIDC for deployment. The process is intentionally boring. It needs a build check, documented cloud settings, and a clear correction path — not a large product-planning ritual.

These are different answers because they are different problems.

Fit-for-purpose is not an excuse for improvisation

“We are being flexible” can become a polite way of saying nobody has decided how work should happen. DA is valuable precisely because it asks teams to be deliberate about the choice.

For me, that means writing down a few things before work becomes expensive:

• the user or service problem
• an acceptance condition that makes “done” testable
• risks that deserve a check or approval
• a source of truth for the decision and the work
• what evidence is needed before the next release or pilot step

GitHub Issues work well for this at the scale of my projects. For Social OS Debugger, I used user stories, acceptance criteria, milestones, and visible labels to make the plan and the verification trail inspectable. For AI-assisted tasks, I label the delegation and retain human review before a change is accepted. The tool is simple; the governance is not absent.

The process should respect both speed and the people carrying the risk

In care-related work, it is easy to say “move fast” from behind a development board. It is harder — and more responsible — to ask who pays if a workflow is confusing, a support handover is vague, or a prototype is presented as something more mature than it is.

That is why project status and limitations belong in public documentation. CareReady’s repository distinguishes working functionality, work in progress, and future scope. The EchoCare prototype states clearly that it is not for clinical or emergency use. ParkinSync excludes non-anonymised source documents from the public repository and checks for accidental publication. These are delivery choices as much as technical ones.

They slow down a careless release. They also make collaboration possible because a client, reviewer, or future teammate can see the boundary of what exists.

A toolkit is valuable when it helps you change course safely

The point of DA is not to mix Scrum, Kanban, Lean, and governance practices until the labels become impressive. It is to avoid being loyal to a process after the context that justified it has gone.

For a small studio, the practical version is modest:

1. Start with the problem and the risk, not the framework name.
2. Choose a visible, lightweight way to plan and verify work.
3. Add controls where the consequence warrants them.
4. Keep the product status and limits honest.
5. Change the process when the work changes.

That approach has helped me move between research-flavoured data work, public web infrastructure, and care-product prototypes without pretending they are identical projects. It is how I want client work to feel too: adaptable without being vague, and careful without becoming slow for its own sake.

For the formal DA perspective, see PMI’s Disciplined Agile overview. The public implementation context is in the ParkinSync and CareReady repositories; my client-facing profile is at hire-veai.com.