Our Scrum team is debating whether to include No-Code / Low-Code Tools in our sprints. Some developers feel it breaks the "definition of done" because the deployment process is different. Has anyone successfully integrated these tools into their Jira workflows? Does it actually speed up the velocity of the squad, or does it create more friction during the peer review process?
3 answers
Integrating No-Code / Low-Code Tools into a Scrum environment requires adjusting your "Peer Review" process. Since there isn't a "Git Pull Request" in the traditional sense, we do "Visual Walkthroughs" as part of our review. It actually increases our velocity significantly for UI-heavy tasks. We’ve found that we can complete three "Low-Code" tickets in the time it takes to do one "Full-Code" ticket. The trick is to clearly define which parts of the system are "No-Code" and which are "Hard-Coded" so the developers don't feel like their territory is being stepped on without a plan.
How do you handle "Versioning" and "Rollbacks" when multiple people are working in the same No-Code / Low-Code Tools environment?
I've found that No-Code / Low-Code Tools are amazing for the "Design Thinking" phase of Agile, letting us test ideas with users during the sprint.
Beverly is right; the "Fail Fast" mentality of Agile is perfectly supported by the rapid iteration speed you get with No-Code / Low-Code Tools.
Victor, that was our biggest headache initially! Most professional-grade No-Code / Low-Code Tools now have "Branching" and "Snapshot" features similar to Git. We make it a rule that no one "Publishes" to the live environment without a second person verifying the snapshot. It’s not as robust as a full CI/CD pipeline, but it has saved us from a few catastrophic mistakes during a mid-week sprint. We treat every major change as a new "Save Point" so we can revert back in seconds if the stakeholders change their minds.