A colleague and friend recently asked me whether agile practices were appropriate when managing development on lowcode or aPaaS (application Platform as a Service) technologies. These higher level languages enable developers to write a class of applications faster and maintain them easier by providing development environments, programming constructs, and other tools. Many of these platforms are designed to rapidly develop mobile applications or applications that connect to disparate data sources. They differ from citizens development platforms and citizen data science platforms which target business end users and enable these user to develop applications, dashboards, and other tools without having to use coding constructs.
How LowCode and aPass Development Differs from Software Development
I reference lowcode development platforms in my book, Driving Digital: The Leader’s Guide to Business Transformation Through Technology as a means for enterprises to develop the tools to empower their workforce and to provide capabilities to tailored customer segments. I’ve used them to develop applications to track the IT budgets, manage a large portfolio of projects, and to establish workflows on hiring and recruiting.
So here are some of the differences between traditional software development and lowcode/aPass development that impact agile practices
| Practice | Software Development | aPass / Lowcode | Agile Impact |
|---|---|---|---|
| Requirements | Requires upfront design and UX with detailed accepted criteria on functionality | Design, UX, and functionality often bounded by the capabilities of the platform | Product owners must know the capabilities of the lowcode platform to stay in its scope of capabilities, but can often draft more simplified requirements and acceptance criteria |
| Development | Can scale from small to very large teams. Leverage standards for coding, commenting, and documentation | Often designed for individuals or smaller teams. Coding and documentation capabilities differ by platform | Enables rapid development around functionality, but documentation may require additional effort outside of the lowcode development platform |
| Testing | Development practice should factor automating unit, functionality, performance and security testing. UAT should focus on user experience | UAT focus on functionality and workflow but specialized testing is often required to validate algorithms | More opportunity to bring business users into the development process to validate implementation while developing |
| DevOps | Dev and Ops teams need to select and implement tools/standards to for continuous integration and delivery | Deployment steps are often factored into the lowcode platform, but platforms may not have the capability to version or rollback a change | Lowcode platforms without roll back and versioning capabilities have higher risks when introducing large functionality or workflow changes |
Recommendations on Implementing Agile in Lowcode
-
- Make sure the application need is appropriate to the platform because trying to use lowcode platforms as a Swiss army knife to every development need can result in applications with poor user experiences and coding complexities.
-
- Leverage shorter sprints to take advantage of the rapid development capabilities and fewer testing needs of the platform. For many platforms one-week sprints are possible.
-
- Focus story writing on workflow and user experience since the technical implementation is bounded by the platform’s capabilities.
-
- Challenge requirements that drive customization and software development outside the capabilities of the platform since this drives complexity in supporting the application.
-
- Add UAT members to the team so that business user testing can occur while development is in progress and ensure “shippable code” at the end of the sprint.
-
- Optimize for shorter release cycles of 1-2 sprints especially if the platform doesn’t have versioning or rollback capabilities.
-
- Require technical documentation with every release to avoid accumulating technical debt and making it difficult to introduce new developers to support applications.
-
- Factor in time to perform and test upgrades so that you don’t fall behind in the supported versions of the platform.
Leave a Reply