Agile Low-Code Development

blog feature image agile

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

Team collaboration
Teams collaborate

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

Agile low-code development needs to be 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:

  • You don’t have to wait for backend integration to be done before you can start building your UI with real data.
  • You can provide a real, testable UI (for UAT) before any backend work has been done.  The simulated DataSource includes the ability to modify data, as well as test out multiple user roles who see the same modified data, just like the final app.
  • Even after deployment, you can go back and use the simulated DataSource mode.  So you can easily figure out if a problem is with the UI or with the backend services.  And you can also continue to develop the UI using the simulated mode, even if the backend services are down, mid-upgrade, or whatever.
  • Because Reify screens have all of their requirements neatly encapsulated with DataSources, you can deploy them anywhere, not just on the Reify platform.  You can deploy them into existing apps, as a partial upgrade to legacy apps, etc, even if those apps use a totally different technology.

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

Change things together

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

Flexible licensing
Flexible licensing

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, 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

Reusable designs
Reusable designs

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

Better communication
Better Communication

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

  • Designers: developers often don’t build what you said, because it was “easier” and your design seemed “overkill”.  Usually, they missed something subtle but crucially important.  Worse, typically their alternative UI is delivered late in the schedule, and when you argue for your original UI, you get shouted down because “we’re too close to the deadline to do rework”.  This situation literally can’t happen if you can participate directly in building the UI.
  • Developers: how many times have you seen an unimplementable spec or mockup?  The designer never got to play with a functioning version of their mockup, so they never realized that a particular series of screens is a dead end, or that there is no way to do X, or that they didn’t need to spec a whole multi-screen wizard because there’s a powerful UI component that can do everything inline instead.  Imagine those kinds of problems never happening again, because the designer is involved in the UI building process, can see the available components, and can’t spec themselves into a corner unknowingly.

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:

  • It’s just so much faster, you don’t have to pick awkward midpoints between two natural milestones, just to fit a meeting date.
  • The UI / backend separation (of Reify, at least) means less necessity of faking, because, the majority of throw-away faked code is related to making fake versions of backend services that aren’t ready yet.

5. Instantly testable: early end-user feedback

End-user feedback immediately
End-user feedback immediately

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:

  • Less throwaway work: with more efficient tools, there is less need to fake things, which is throwaway work.  This is especially true if your Agile low-code development platform offers that critical UI / backend separation discussed above, which avoids the problem of having to “fake” backend services that aren’t ready yet.
  • No more grunt work replicating mockups: developers hate this kind of drudge work.  With low-code, the mockup is the prototype and the real UI.  No more drudge work.
  • Reduced miscommunication: when the designers participate in building the UI, miscommunication is greatly reduced.  Miscommunication is itself a source of burnout, not to mention miscommunication that leads to wasted work
  • Less fighting over priorities: arguing over which is the most worthy near-term goal can create a lot of friction.  With low-code, you can simply do more, so there is less of a need to fight for your favorite: you can do your favorite and someone else’s top priority

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


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.

Get a demo of Reify

Experience a live demonstration of the Reify low-code platform customized to your specific needs!

Similar Posts