Four Pitfalls of Low-Code Application Development

IT teams across industries are embracing low-code as the new way to build applications. It’s not just faster (producing powerful applications at 10 times or more the speed of traditional development) but, done right, low-code means you can deliver better functionality, rely on smaller, more versatile dev teams, and optimise collaboration with users.

Unfortunately, many IT teams are only scratching the surface of low-code’s potential. Why?

Because they’re running low-code projects with high-code approaches. To get the full power of low-code, you can’t just replace Java with a low-code platform and run everything the same way you always have. You need to forgo outdated, bloated development approaches and instead adopt some key team and product design approaches.

Here we look at the four most common pitfalls of low-code application development and how you can combat them with a modern low-code approach.

Pitfall 1: The development team is too big and too specialised

Traditional application development teams are large, specialised, and full of excessive inter- and intra-dependencies.

Whereas the best low-code teams are built to move quickly and minimise dependencies. They’re small, with all the skills you need to go from idea to application. And they stay together across projects so they don’t have to spend time learning how to collaborate. Low-code teams are designed to be collaborative and egalitarian, full of people who can be described as for instance, developer and tester or developer and Scrum Master. Everyone from team leads to architects will develop features. And every developer should have at least one additional specialty area — UX design, testing, architecture, etc.

Since low-code is easier to learn than high-code, specialists in fields such as UX, ethnography, testing, and business analysis can be cross-trained as low-code developers. These newly created “generalised specialists” provide overlapping skills that allow you to build development teams differently and unleash the full power of low-code. Low-code optimised teams have lower costs both in terms of labour (less people, fully utilised) and product (truly cross-functional and collaborative teams are much more likely to build the right product).

Low-code teams deliver a faster time to value because their versatile makeup removes internal bottlenecks and reduces external dependencies (e.g. no need to wait for a database specialist to free up if they are database expert and a low-code developer within the low-code team).

Pitfall 2: You’re not digging deep enough into the problem

Traditional development approaches rely on business analysts who act as translators between business users and technology teams. The two domains are siloed from each other, which means the people experiencing the problem are separated from those most equipped to solve it: developers. Developers attempting to fully understand the problem are stymied by low-fidelity communication channels (e.g., email), imperfect translators, latency, overreliance on documentation, and, most damaging of all, no access to end users.

Instead of programmers with a decade of Java experience, look for developers who are more interested in solving problems than writing code. They may have one or two technical specialities as well as general knowledge of software development and the business domains in which they work.

As you find the right people, you should also foster a culture of asking open-ended questions. Instead of asking “Is compliance an issue?” ask “What happens if compliance is not met?” Never take requirements at face value. Encourage developers to probe deeper, ask “Why?,” and discover nonlinear solutions.

This starts during project initiation — often called Sprint 0 — with collaborative sessions that include IT, business sponsors, and end users. Work together to define goals, explore what the application must do to reach those goals, and map out a plan to deliver a valuable product. The intent is not to define every detail of your project, but to plan well enough that you start off in the right direction.

Pitfall 3: Feedback is slow, scarce, and distorted

Low-code removes obstacles that slow high-code projects down. With traditional development practices, feedback loops are like a ferry travelling between two shores. Business users are on one side, and the developers building the application are on the other. You ferry information back and forth slowly, in a high-latency process that risks a lot of distortion.

The best solutions emerge when business users and developers create applications together. Instead of ferrying feedback back and forth, low-code builds a bridge between developers and business users. It makes collaboration easy and encourages clear, frequent input, which helps you test assumptions along the way to finding the right solution.

Increased collaboration and iterative development also help you get early buy-in from stakeholders. Rather than development happening in a silo and all the value coming at the end of a project, end users can validate and influence the application as it takes shape before their eyes. Prototypes and in-progress builds give users something concrete to react to, accelerating the design process by ensuring your development team has a clear understanding of what’s needed.

Pitfall 4: Success is only measured at go-live

Deployment is a meaningful milestone. But if your application isn’t used or if users are unhappy, it will never deliver value.

So, how do you make an application successful? First, you need to ensure it’s adopted and evangelised. This starts at Sprint 0 when you build an understanding of your users’ needs and pain points.

You can continue building goodwill throughout the development life cycle by identifying a few key stakeholders who are well respected among your user group. As often as possible, include these evangelists in these ways:

• Invite them into the design process to give input and ask questions.
• Then ask them to go back to the larger user group to talk about what’s being built.
• Hand over the demo keys so they can run a showcase demo for the broader user group.
• Crowd-source feedback from them and other users.
   

It’s important to request user feedback and take questions. Even more importantly, build in opportunities for IT to take a backseat so users can shine. The goal is for the application to become as much theirs as it is yours.

How to optimise low-code development

It doesn’t matter whether you’re just getting started with low-code or scaling low-code across your organisation. Adopting a few agile best practices can transform long timelines and just-OK applications into rapid development that delivers outstanding results.

Find more best practices, tools, templates, and other resources to optimise your low-code application development efforts in the Appian Delivery Methodology.

Image credit: ©stock.adobe.com/au/tippapatt