Scaled BMAD for large scale enterprise projects #2297
paveljakov
started this conversation in
Ideas
Replies: 1 comment
-
|
Thanks for sharing - I am actually about to make some changes and publish a guide on this very topic as I also have been rolling out bmad across a few large enterprise and run into the exact things you bring up and with similar solutions! I forget to check the discussions frequently - but if you are in the discord community and would like to chat on the topic further please reach out to me - but more info and doc guidance also to come on this soon with more changes! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
I wanted to share an idea how we are applying and scaling BMAD in my company while delivering enterprise software to our clients. First of all BMAD OOTB provides a lot of nice features (party mode, specialized agents, research, etc.) that supports our POs, Architects and DEVs work. The issue we have encountered however was how to apply BMAD in enterprise software delivery environment where projects are built by multiple teams, multiple POs, etc. There is no way to have a single PRD file or sprint status file for e.g. entire countries internal revenue service system or similar software. No to mention that company has established processes and tools that must be used to track and manage projects.
The simple solution I have found and currently slowely applying in a few smaller projects is lightweight customization layer on top of BMAD that augments the workflow and allows to scope BMAD not for entire project, but for one feature at the time. Size of the "feature" depends on individual projects, but rule ot thumb would be one epic (user authentication, landing page, user dashboard, request submission process, etc.). Each feature can be owned and worked on by different POs. When feature is ready stories can be created (new, follow-up, etc.) in and pushed to Jira and PRD pushed to Confluence. In this setup we do not have local PRD or Epics file, source of truth is Confluence and Jira, POs do not need to learn to use GIT. If PRD needs to be extended, modified, etc. any PO can pull it from Confluence and work on it. Stories in Jira are not BMAD implementation stories, but standard implementation stories containing ACs and mapping to FRs/NFRs they implement (similar what we would find in epics.md file). When implementation needs to start DEVs can just provide Jira link and using Atlassian MCP all data can be pulled from Jira, Confluence, Figma, etc. and implementation story created just like normal BMAD and standard implementation workflow continues. Cross feature dependencies can also be resolved by POs steering and AI agent self-knowledge of the system. For now such scaled setup seems to be promising.
If anyone is intersed in implementation, it is quite simple, small wrapper skill on top of bmad-create-prd to inject context and instructions to scope PRD creation to indicated feature, not the whole system (editing, validating works OOTB). Then wrapper on top of bmad-create-epics-and-stories to similarly augment epics creation and afterwards additional logic to publish stories and PRD to Jira and Confluence. And wrapper on top of bmad-create-story to support Jira ticket as an input and use ticket description, ACs, link to PRD, Figma, etc. to build implementation story that then can just by pointed to by the bmad-dev-story.
I am very eager to see return of agent customization feature and workflow customization that maybe would enable implementation of similar customizations using OOTB BMAD customization capabilities.
Beta Was this translation helpful? Give feedback.
All reactions