Agile Low-Code Development

Low-code is a perfect fit for the Agile methodology.  The low-code approach not only meshes well with the Agile process, it actually fixes some of Agile’s flaws and drawbacks.

In this article, we’ll explore the perfect synergy that is Agile low-code development.  We’ll begin by defining the ideal traits and capabilities of a low-code platform that is meant to be used for Agile development, then we’ll explain how those capabilities can supercharge Agile development.

We’ll organize the traits into “Must Have” and “Very Nice to Have”.  Where necessary, we’ll explain how these features work using the Reify low-code platform as an example, but these capabilities are available from multiple platforms.  If you are looking to adopt an Agile low-code development process, this list of traits can also serve as a checklist for evaluations.

Here we go!

Must Haves

1. Web-based builder

Agile is all about collaboration, so for Agile low-code development to work, we need designers and developers working together in the same web-based environment. Fluid collaboration is a must, and that’s not going to work if there is a downloadable application that must be installed and configured, especially if the tool requires dependencies (like Docker, npm, a JDK, Eclipse, etc) that designers wouldn’t normally have already installed.

For this reason, a low-code platforms like Outsystems, which requires an IDE-like download, is not an ideal choice for Agile low-code development. Even if the download & setup process is simple, most people assume it’s not – and the reality is, there’s usually at least one annoying hurdle, whether it’s registering for an account, acquiring a license, or having to download some dependencies. For Agile to be agile, you want your low-code tool to simply be available as a URL, and that’s it – in my opinion, nothing else will do.

Note that here, by “designer”, we mean people doing functional design, that is, business analysts, product managers, user experience experts, etc; people who typically write specs and create mockups showing how an application works rather than how it looks.  Reify and other low-code tools also have capabilities for people doing aesthetic design (theming, etc), but in this article, we’re using the words design & designer to refer to functional design.

2. Simple builder UI

The builder UI must be understandable to non-programmers, specifically, non-technical designers must be able to build powerful, sophisticated apps without developer involvement.  It should be about as easy to use as typical mockup tools, like Balsamiq or Lucid.

This is really hard to get right, and a lot of low-code platforms “cheat” here: there will be a video explaining how to do something, then in the middle of the video, the narrator types in a “magic expression”: an XPath, a SQL statement, a JavaScript snippet, whatever.  When you need a “magic expression” like that, you just made your builder inaccessible to 90%+ of all designers.

So, for example, in the low-code system Retool, videos show users constantly typing in templated SQL or JavaScript expressions. There’s a really neat auto-complete system, but no amount of auto-completion is going to get a non-developer comfortable with constantly writing little bits of code. And that means non-developers are locked out of the collaboration process, a major problem for blending Agile with low-code.

With Reify, we have been very, very careful to make sure our builder is truly usable by non-programming designers.  In fact, we were recently asked by one of the world’s largest banks (you’ve heard of it) to build a prototype of an investment analysis tool.  They expected code but we had one of our Product Managers (not a coder) build the whole thing in Reify.  The application involved multiple related entities, navigating those relations and various complex requirements around search and data grouping – all done in Reify without any “magic expressions”.

3. Fast

For reasons that will become clearer in the second half of this article, the builder tool must be fast – not just responsive, but bristling with shortcuts, accelerators, intelligent defaults, “Skip” buttons, etc.  An experienced user should be able to use the tool in front of other people and those other people do not get bored and start looking at their phones.

That’s a high bar, but it can be done.  Remember the Product Manager who built the prototype for a bank, all in Reify?  After we showed the finished prototype to them on a Zoom, she built it again, right in front of them.  It took all of 5 minutes, and no one asked her to skip ahead, because Reify is so fast that she could read out the requirements and build to those requirements at the same pace.

We’re talking about Agile low-code development here, so let’s actually be agile!

4. Instant, testable share

You must be able to share a runnable prototype instantly, ideally as just a URL that immediately starts the prototype.  What is shared must be runnable and suitable for a UAT (User Acceptance Test), not just a set of screenshots, or a Balsamiq-like set of mockups with limited interactivity.  

Specifically, you go to the shared prototype, and you can search/sort/filter the sample data, try out data entry, receive validation errors, everything.  That’s a truly testable prototype, and for Agile low-code development to really work, nothing less will do.

5. Separates UI and backend

You need to be able to build the UI and just tell the tool: this is what we expect the server data to look like.  This allows you to just proceed with building the UI, without having to wait to connect to the services the app is expected to eventually integrate with.

Reify does this with the concept of DataSources.  At design time, a DataSource simulates how you expect the backend service to eventually work, including search/sort/group/edit/validate/save etc.  Later, when you go to deploy, if you’re using the built-in Reify backend, you’re done: just push “Deploy”.  If you’re connecting to some other service, the DataSource provides a clear contract for how that service is expected to behave.  

And DataSources are trivial to create: type in or paste in some CSV data and you’re set.  It’s 100% something that a non-programmer can understand and can do.

It’s difficult to overstate just how powerful this is.  It means:

Hence, we list this under “Must Have”.  It really is!!

6. Cannot be “no-code”

This may be controversial, but in my opinion, if you’re building things that are so simple that a purely no-code platform can handle it, and you can be confident that code will never be needed, even in version 3.0, then you don’t need Agile or scrums – you’re building something pretty basic.  Another way to come at this is: if you can really do everything in a no-code tool, then there is sure to be COTS (Commercial Off-The-Shelf) software that can do what you need, without needing to build a custom app yourself.

Very Nice to Have

1. Accountless sharing (“publish”)

Many of the most interesting Agile low-code development projects involve cross-organization collaboration, or even spontaneous coordination within different parts of a single, large organization.  Your low-code platform shouldn’t stand in the way of this – you should be able to “publish” your work such that a secret URL is all that’s needed to access a working prototype.  Note for the security conscious: this can be for behind-the-firewall sharing only, also, it’s easy to turn off the feature if it’s just too scary.

2. Live mode

In Reify, you can share a URL to a project you’re working on in “live mode”, meaning, as you continue to work on the project, every time a change is made, the page auto-reloads and shows the revised UI.  This is really key for in-person or virtual meetings, where you can have people discussing the design as changes are made to it on the fly.

The alternative is saying: “OK everyone I put a new share up, it’s called this” or “I put the new URL in chat”.  That’s fine if you’re going to make maybe one change during a given meeting.  But that would not be agile development; Agile low-code development is where you make 20 changes during a 45-minute meeting, and everyone sees them immediately.

3. Flexible account pool

Licensing concerns may seem out of place in a list that is otherwise mostly technical capabilities, but, you know what?  Burdensome licensing kills collaboration.

How many times have we all encountered: “OK, to see the latest, just download something from here, register for an account here, go talk to Cindy to get the access key… oh but if we’re out of accounts talk to Mark..”

People have better things to do.  Onerous licensing kills collaboration.

With Reify, we’ve paid close attention to this problem: we offer multiple models, so it’s too much to go into here, but, in short, we focus on making unlimited accounts affordable, and where things must be tracked, we make the invitation process as simple as possible (i.e. if you’ve got a share URL you can just go into the tool, see how it’s built, try out changes, then create an account if you want to save).

Truly Agile Low-Code Development

OK, now that we have our dream tool, let’s see what Agile low-code development could look like – how will this ideal low-code tool solve Agile’s flaws, and deliver on the full promise of Agile?

We’ll approach this by taking a look at some of the common ways in which Agile fails, or just doesn’t work as well as it could, and see how an Agile low-code development process can fix those problems.

Before we start: I can just imagine all you angry scrum masters loading up Scrum.org, prepared to fire one of those “Agile Myths” articles at me that moment I talk about any issues with Agile.  I have two things to say about that:

1. You can call these problems “myths” all you want, but these problems actually happen.  I see them all the time.  The “Myths” articles offer reasonable solutions, but those solutions often run up against schedules, politics, incompetence and other externalities.  Being able to avoid Agile’s pitfalls in an additional way (via an Agile low-code development process) is a good thing, and can help Agile spread and improve.
2. I would readily agree that an excellent scrum master with a strong team can definitely avoid most of Agile’s pitfalls.  But when you have a talented team like that, it will succeed with literally any methodology.

So, put down your email client and back away slowly; I don’t need any more emails about Agile myths, I’ve read all the articles already!

Instead, let’s take Agile to the next level, by combining it with an ideal platform to create an Agile low-code development process that really rocks.

Here are the common issues with Agile, and how low-code platforms like Reify can solve them:

1. Too much discussion over too little progress

In Agile, you’re generally trying to make minimal incremental progress that can be usefully reviewed.  But the reality of classic IDE-driven development is that not that much progress can be made in just a couple of days.

So many times, I have seen an absurd situation like this: “OK, I built the login button as we agreed, and when you click it, it opens a dialog saying you’re logged in.  But you’re not actually logged in; that’ll take a while to build.  Also, in the real app, there won’t be a dialog telling you that you’re logged in…”

And somehow with this progress, it’s time for another meeting.

Low-code platforms, especially fast low-code platforms like Reify, make it possible to deliver real progress between meetings.  No more lengthy discussions over trivial changes.

2. Parallel work

Usually, in Agile, designers only contribute mockups to the development effort, and once implemented, those mockups are thrown away: it’s wasted work.

With low-code tools, especially low-code tools that are actually usable by designers, there’s no need for separate mockup tools.  The “mockup” is the application.

When you combine this with the UI / backend split discussed above, this is extremely powerful: the developers and the designers just need to agree, at a very high level, on roughly what the data looks like (again, in Reify, a few lines of CSV data is sufficient).  Then, designers build the UI while developers worry about backend concerns.  The DataSource provides a kind of “contract” between the two halves of your team so that nothing can get out of sync.

In just this one aspect, you have something like a doubling (or more!) of productivity.

3. Reduced miscommunication, since designers build most UI

With Reify, the designers actually build functioning UIs.  Think about how powerful this is, in terms of avoiding miscommunication:

Agile is about reducing miscommunication, but Agile low-code development can all but eliminate the remaining sources of miscommunication.

4. Zig-zagging & waste

Because of Agile’s insistence on extreme near-term goals, often, the progress needs to fit the next meeting, rather than the meeting fitting the next meaningful milestone.

Yes, I know, this is another “Agile myth”.  You just schedule meetings dynamically based on the natural milestone, right?  Except: Erik needs to pick up kids early on Friday, Rishad has a standing meeting with marketing on Thursdays, Shen has a dentist appointment this week, and the team is split across 3 very different timezones as well.  

Flexible meeting schedules for Agile usually don’t work.  I’ve seen multiple Agile teams try to adopt a flexible meeting schedule, only to find that they were spending more time on scheduling than on actual work.  They then go back to a fixed meeting schedule.

So there’s going to be a fixed meeting schedule.  And what this means is that as the milestone is adjusted to fit the next scheduled meeting, extra work is done in order to have something to discuss: something is entirely faked, and the fake code is later thrown away.  Or something is built in a temporary way and then re-written.

That’s wasted work, pure and simple.

Low-code avoids this, in two ways:

5. Instantly testable: early end-user feedback

Agile is about getting feedback early and often.  Usually, that means feedback from designers to developers regarding incremental progress.

However, the most important form of feedback in any software project is feedback from actual end-users who will be using the software.  Very often, the designer likes what they see, but when you get an actual end-user in the room, they say something like: “why would I use this?”.

With low-code tools, especially ones that can give you an instant, shareable, functioning version of an app that is in development, you can solicit end-user feedback early and often.

No more painful late-project course corrections!

6. Incessant sprints & Agile burnout

When you sprint, you normally stop to catch your breath before you sprint again, right?  Not so with Agile.

That was half a joke, but mostly, it’s a reality: despite “sustainable working pace” being one of the core Agile principles, Agile burnout is a thing.  Having a series of extremely near-term deadlines (“sprints”) just grinds on people.

Low-code platforms work against Agile burnout in multiple ways:

Low-code, and especially Reify, can make Agile a joy again.  The fast pace of Agile fits the fast pace of low-code.

Conclusion

Agile low-code development truly delivers on the original promise of Agile.  Low-code tools, if they have the proper features, have the ability to supercharge Agile development and reduce or eliminate many of the problems that typically plague Agile teams.

About the author

Charles Kendrick has been the head of Isomorphic Software for over 20 years. He is the Chief Architect of SmartClient and Reify Both products are heavily used and very popular amongst the Fortune 500. He has successfully worked with and coached dozens of teams applying Agile approaches and is a pioneer in Agile low-code development.