Agile development provides many benefits to software development, if executed well. I’m not going into a lengthy definition of the intricacies and pitfalls of how you run an Agile development project. This article takes a deeper look at one aspect of Agile: The Sprint.
Perhaps slightly over-simplified for the most puritanical Agile process enthusiasts out there, this short description for The Sprint provides a good starting point to build a discussion: A sprint is a short race to a defined end. It’s simple. It’s straightforward. It’s short.
The most often used sprint duration is two weeks. So, in two weeks you want to achieve a set goal, or goals, with a defined result or deliverable. Business and IT work together and fine-tune what is being achieved during the Sprint. It’s like rapid prototyping, but you don’t want to throw it away afterwards.
Now let’s consider the emerging low-code development platform movement. One of the first things to make clear is that it is not “no-code” – but “low-code”. I make this distinction quite clear, because at some point, if the defined end-goal of a Sprint includes a real business application with at least a few complex business rules and multiple data sources, some coding will be required somewhere.
Don’t slow down your Sprint to a Stroll
The goals of low-code mesh well with the Sprint concept. Low-code provides a developer with the capability to rapidly build complete applications that can span multiple user experiences (for example web and mobile). A good low-code platform handles all the underlying tedious and mundane aspects of software development, like creating the data layer, handling communications between the front and back ends, addressing cross-browser inconsistencies, negotiating integration between disparate data sources, etc.
There are plenty of examples in the real world where we apply technology to make the task quicker. We use cars instead of a horse and buggy. We use chainsaws instead of axes. Engine powered ships replaced sails and so on…
Yet many Sprinting development teams are still holding on to development tools that require loads of effort and programming tediousness. And thus, their resulting Sprints do not actually result in potentially shippable software as their methodology suggests.
Their pretty and spatially planned multi-coloured 3M sticky-notes won’t compensate for the self-limiting assumptions they have accepted to conjure the notion of a Sprint. It’s simply a chunk of work being performed in two weeks with the accepted defined result of that with which the next two-week Sprint will commence work with in one fortnight.
Some may argue that the use of frameworks addresses much of the mundane coding. However, this author has seen numerous frameworks come and go over relatively short periods. This is adding to the cost of development – not reducing it. It means that an organisation is producing “legacy applications” at an alarming rate – because these applications need to be maintained; and having three, four or five different frameworks is creating a productivity drag – like barnacles on a ship – and deepening technical debt.
Get more out of your Sprint with low-code
To become truly agile, it is crucial to move to a low-code application development approach. Consider these important elements when selecting a low-code development platform to transform your Sprints from fortnight chunks-of-work to end-result-bearing races:
- Visual creation of UI components – allow the developer to easily develop UI views and have the software handle underlying areas such as swapping between views in a Single Page Application model.
- Assist the developer in styling with built-in support for Google’s Material Design. Including complementary colour schemes.
- Provide a “Mobile First” approach to UI development, including responsive design handling. But don’t forget about your power users! When building desktop applications, make sure you can strike a different balance between UI screen real estate and productive control.
- Create a Data Services layer for accessing underlying tables and insulating your UI and business rules from the details of database access.
- Support for collaborative development.
- Support for one-click deployment, whether that be to on-premises servers or cloud environments.
- Make it easy for developers to re-use components.
- Provide a business rules engine to centralize tasks like data validation, and the synchronization of data management across multiple user experience deployments, etc.
- Make it easy to do active prototyping – where this work is retained in the actual development.
- And after it’s in Production – make it easy and quick to maintain.
The Agile Sprint has provided a great approach for building modern complex business applications. Developers need to update the tools they are using to get more out of Sprints. Throw away the axe and grab your chainsaw!
