Do not begin by announcing a company-wide BMAD transformation. Begin with one repository, a small cross-functional group and a change that is valuable but recoverable.
Good first pilots include adding a small API endpoint with clear rules, improving a recurring operational workflow, replacing a manual report with a governed service, adding a feature to a well-tested internal application, or documenting and fixing one known pain point in an older system.
Avoid making the first pilot a core system replacement, an emergency production incident or a politically exposed programme. The point of a pilot is to learn how the method behaves on your work, and you learn very little when everyone is under pressure to declare success.
Mopane Logistics is fictional, and its systems and figures are illustrative. After the broken finance export described in Part 1, Mopane's tech lead proposed a ten-week pilot. The product owner chose the first change: a request support agents had been making for a year. When a customer says they never received an invoice, the agent currently emails finance, finance finds the invoice and resends it, and the customer waits a day. The agents wanted a button in the customer portal's support view that resends an existing invoice, without needing access to the finance system.
It was a good pilot. It was valuable, contained, reversible, and touched identity, audit and an external email service, which gave the method something real to work on.
Choose the version deliberately
As of 13 October 2026:
- The official repository identifies v6.12 as the stable line, with v6.12.2 the latest release. The project describes v6.12 as frozen except for bug fixes.
- v7 is a preview alpha. It changes frequently, and updates can break existing setups.
- The two lines install differently. The documentation site now describes the v7 preview; the v6.12 documentation lives alongside the stable code in the repository.
For a production-oriented pilot, stability usually matters more than novelty. Mopane pinned the stable line. A small technical team that wants to try the preview should pin that too, expect changes, and keep its artefacts in plain files that any tool can read.
On the stable line, installation runs from the project directory:
npx bmad-method install
It needs a recent Node.js, and some skills also use Python. Check the current official instructions before running it, and confirm that the documentation you follow matches the version you installed. Do not copy a command from an undated blog post, including this one, without checking.
Settle five things before installing
Before Mopane installed anything, the tech lead wrote down five answers and had the product owner and group IT's security reviewer agree them.
| Item | The question |
|---|---|
| Repository | Which code and documentation are in scope? |
| Authority | Who approves product, architecture, security and release decisions? |
| Tool access | What may the AI read, change, execute or send outside the organisation? |
| Engineering controls | Which tests, scanners and review gates must pass? |
| Data boundary | What information must never enter the AI tool or the generated artefacts? |
None of these is specific to BMAD. Every AI coding pilot should answer them. They matter more with a structured method because the method produces durable artefacts, and anything that goes into an artefact stays in the repository long after the conversation ends.
A safe first run
- Create a branch and record the current baseline: build time, test results and open defects in the area.
- Install the chosen BMAD line from current official instructions.
- Add the project's coding, security and architecture rules as maintained context.
- Choose one bounded change.
- Ask the method to help size how much planning the change needs.
- Review the intent and specification with the people who own the change, before any code is generated.
- Let the build step work only inside the approved repository and branch.
- Run the deterministic tests and security checks.
- Hold a human code review and a product review.
- Record effort, defects, rework and any context that was missing.
Step 3 deserves a word. Mopane already had an AGENTS.md file in the portal repository with a few lines of coding conventions. The team expanded it with the things a newcomer, human or AI, would need on day one: the supported libraries, the logging rule that personal information never goes into application logs, the approved email service, and the fact that Dispatch is read-only from the portal. Every AI session in the pilot started from that file.
The change brief
This is the change brief Mopane's product owner wrote for the invoice resend. It is short, and it carries authority, boundaries and evidence:
# Change brief: resend an existing invoice
## Outcome
Support agents can resend an existing invoice to the customer's
billing contact without access to the finance system.
## Users
Authenticated support agents serving current customers.
## Constraints
- Use the existing identity provider and support-agent role.
- Do not create, change or cancel invoices.
- Send only to the billing contact already on the customer's account.
- Record who requested the resend, for which invoice, and when.
- Reuse the approved email service.
- No personal information in application logs.
## Out of scope
- Changing invoice content or recipients
- Bulk resends
- Customer self-service
## Success evidence
- An authorised agent can resend an existing invoice.
- Unauthorised users are refused, and the refusal is audited.
- Repeated clicks do not send uncontrolled repeat emails.
- Tests cover success, refusal, missing invoice and email-service failure.
A brief like this is more valuable than a long, generic prompt, because every line answers a question the build would otherwise answer by guessing.
Look at the third constraint. It was not in the product owner's first version. The specification step, run with the product perspective, produced a tidy specification that included an optional "send to" field so agents could type in an alternative address. Nobody had asked for it. The assistant had inferred it from the way support agents described customer complaints. At step 6, the security reviewer spotted it immediately: a free-text address field on an invoice resend is a ready-made route for sending a customer's financial documents to an attacker who has phoned in pretending to be the customer. The field came out, and the constraint went in.
That catch is the clearest argument for step 6. The assistant did not do anything wrong by its own lights. It filled a gap with a plausible feature. The review is where the team decided which gaps to fill.
A one-page pilot charter
Mopane's charter fitted on a page. A version you can adapt:
# AI delivery pilot charter
## Outcome
[The business or delivery result]
## Scope
[Repository, product area and change class]
## Method and version
[Pinned BMAD line and installation source]
## Team
- Outcome owner:
- Technical owner:
- Security or risk reviewer:
- Participants:
## Access boundary
- Allowed repositories:
- Allowed tools:
- Prohibited data:
- Network access:
- Production access: none
## Required gates
- Specification review:
- Architecture review (where needed):
- CI tests and scans:
- Code review:
- Release approval:
## Measures
- Lead time:
- Rework:
- Defects:
- Review effort:
- AI cost (rand):
- Human interventions:
## Stop conditions
[What would pause or end the pilot]
The stop conditions are the line teams most often leave blank. Mopane wrote two: any finding that personal information had entered an AI tool or artefact outside the agreed boundary, and rework after review higher than the previous quarter's average for three consecutive changes.
The first retrospective
After the invoice resend shipped, the team held a one-hour retrospective around six questions:
- Which questions exposed real uncertainty?
- Which artefacts were still useful after the workflow moved on?
- Where did the AI invent an assumption?
- Which context should become a permanent project rule?
- Which steps added ceremony without reducing risk?
- Would we use the method again for this class of work?
Mopane's answers were mixed, which is what an honest pilot looks like. The invented "send to" field went into the record as the most valuable catch. The specification and the change brief were still useful a month later; a separate product brief the team had generated for the change was not, and nobody read it again. The team decided that changes of this size skip the product brief. The rule "send only to contacts already on the account" went into AGENTS.md as a permanent project rule, because it would apply to every future customer communication.
The goal of a first pilot is not to prove that BMAD works. It is to find out where it helps your delivery system and where it only adds paper. For a broader adoption sequence beyond the first pilot, see our SDD adoption playbook. For the controls that sit around any AI coding tool, see harness engineering.
The short version
Pilot one bounded, recoverable change. It should be valuable enough to matter and small enough to undo.
Pin a version on purpose. Stable for production-oriented work; the preview only with eyes open. Check that the documentation matches the version.
Settle five boundaries before installing. Repository, authority, tool access, engineering controls and data.
Review intent before code. It is the step that catches invented assumptions while they are still cheap.
Retrospect honestly. Keep what reduced risk, drop what only produced paper, and turn new knowledge into project rules.
Previous: Part 2, from idea to working change. Next: Part 4, greenfield and brownfield are different games. All parts are on the series page.
How CloudNala can help
We help teams set up a first AI delivery pilot that teaches them something. We choose a bounded change and pin a method version. We agree the repository, authority, tool and data boundaries with your security reviewers before anything is installed. We write a one-page charter with measures and stop conditions. We facilitate the retrospective that decides what to keep, what to drop and which lessons should become permanent project rules.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan an AI Delivery Pilot or write to us at consult@cloudnala.co.za