“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

It’s no accident that this statement is principal number 1 in the Agile Manifesto. It is the goal that agile teams all over the world struggle to achieve every day with varying degrees of success. According to Forrester Research, the low-code market is growing at nearly 40% to help organizations achieve this often elusive goal by reducing the time to build, test, and deploy valuable software.

Furthermore, a recent study about the State of Application Development revealed that companies that have adopted low-code have an 8 percent higher organizational agility score compared to those not using low-code.

The thing is, a highly mature agile culture helps organizations maximize the benefits of low-code development platforms by combining the fast decision-making of agile with fast development speeds. Nevertheless, many agile teams overlook the specific changes needed to their existing agile practices to maximize performance with a low-code platform.

Top Challenges of Introducing Low-Code to Your Agile Team

Whether you are in an organization considering low-code, currently part of a low-code development team, or in a high-performing agile team curious about low-code, you should look closely at three specific aspects of developing with low-code and determine how to tailor your organization’s flavor of agile.

1. Low-Code Development Really Is Faster

Even high-performing, mature agile teams are rarely prepared for the increased development speed when building with low-code for the first time. Agile teams that are still progressing on their agile maturity journey find adapting to the speed of low-code even more challenging.

In particular, teams often find it difficult to maintain a sufficient backlog of development ready user stories because of the increased development velocity. This can result in several problems including:

  • Developing low-value stories because they are the only ones ready
  • Starting sprints without enough committed stories
  • In extreme cases, developers sitting idle.

Maintaining a healthy backlog can be a challenge for all teams, but it can be even more challenging at the speed of low-code.

2. Speed with Quality

While speed is an important measure of value with low-code, speed with quality is the ultimate goal. In addition to creating and maintaining the user story backlog, teams new to low-code can find it difficult to achieve the necessary quality from the start of the process using their existing agile approach.

Without quality built into the process from the start, teams often find it difficult for testing teams to keep up with new development and managing the bug fix cycle in particular. The end result is fewer user stories meeting the definition of done at the end of each sprint.

3. Stakeholders Moving at Different Speeds

Another common challenge low-code teams face when working in large organizations or projects with many integration points is the significant difference in development velocity between co-dependent teams. Teams building enterprise applications using low-code which have dependencies from internal and external teams working with waterfall or low maturity agile processes, often find their work slowed or blocked by those dependencies.

Even waterfall teams used to work with agile teams, are often unprepared for the demands resulting from the increased of a low-code team which can result in missed deadlines, costly API mocks, and increased technical debt.

Maximizing the Power of Low-Code: Tips and Tricks

In the situations described above, agile teams who are new to low-code development often try to keep up the pace by making small changes to their process or, most often, by simply working more hours. The latter ultimately yields limited improvement and frequently leads to lower team morale.

Rather than pour more hours into the problem, agile teams should look for opportunities to adapt and improve their agile processes in five key areas to maximize the increased quality with speed that comes from developing with low-code platforms.

Laser Focus on Backlog

If you don’t have a strong product owner, stop now and find one; this is a key role that will significantly help you succeed.

We say it all the time, but really—especially when developing with low-code—success starts with having a high-performing product owner who is engaged, empowered, and responsive. For example, if you are used to refining the backlog once a week or once per sprint, you need to increase your cadence. Maintaining a well-groomed backlog of stories and meeting the definition of ready require daily attention and a fast decision-making process about the priority, content, and acceptance criteria of your user stories.

The demands on your non-IT stakeholders will increase as well. You will be delivering more functionality for review and approval faster than in a non-low code project. Stakeholders who you rely on to provide requirements, documentation, and feedback to build and maintain the backlog will need to be more responsive than they have been in the past.

Since these stakeholders are normally the ones requesting the application, they should be happy, but they need to understand their increased responsibilities and the urgency of providing you information and feedback. You will likely need to provide more training, role definition, and more frequent collaboration with those stakeholders.

All team members (not just the individuals writing user stories) should understand how to write user stories in a consistent format and with very clear acceptance criteria. During development, team members will often need to understand, interpret, and make on-the-fly constructive suggestions about how to refine stories. It can be helpful to keep the user stories short with low-code because it simplifies development, increases throughput, and shortens testing in alignment with the faster development cycles. If you’re writing long stories or not using acceptance criteria, stop and fix that or ask for help.

Increase Collaboration

Many low-code platforms make it easy for technical and non-technical team members and stakeholders to collaborate in real-time and reduce the development cycle.

When building new functionality, developers and business analysts can collaborate from the start of the development cycle, especially for complex user stories. For example, some low-code platforms include workflow visualization where the developer can show the business logic and data in the code visually in non-technical language. The analyst can provide feedback, the developer can make changes, and the change can be tested in real-time significantly reducing defects, missed requirements and costly feedback cycles.

When refining stories during a sprint, traditional development platforms require asynchronous feedback loop cycles where the user writes the story, the developer goes away writes the code, tests the code, deploys the code, and the user reviews the page. With low-code, the user and developer can frequently review a screen together and discuss the changes. The developer can then make the change and publish the code, which can be reviewed by the user and developer together—in real-time. This requires a change in the current process, but the reduction in cycle time and wasted effort is significant and worth the investment to change your process.

Developers and QA testers who embrace collaboration can reduce the cycle time for fixing defects. As with the example I mentioned before, high-performing teams often have developers and QA team members collaborate in real-time to fix defects rather than focusing on the time-consuming process of identifying, documenting, triaging, prioritizing, fixing, and retesting defects.

Eliminate (or Mitigate) Dependencies Early

Products today almost always have some type of dependency on integration points, data dependencies, security requirements, or other issues. If your team is working with low-code and the other team is not, you will need to change your approach to identify and mitigate those dependencies much earlier than in the past. No one-size fits all approach can fix this problem, however, you can consider the following options:

  • Pay more attention to identifying potential dependencies.
  • Flag even low-risk dependencies and track them daily.
  • Negotiate shorter SLAs with the dependent team.
  • Remove the dependency by building it in low-code.

You should avoid consistently building workarounds, like API mocks, which lower velocity as a result of changes to existing functionality, increased technical debt, and duplicated testing. What is important is that you recognize that strategies that worked in the past will likely be less effective when developing with low-code.

Increase Ceremony Efficiency

As you mature with agile, you should look for ways to streamline the agile ceremonies without losing their value or intent. A low-code development project is a perfect opportunity to experiment with and implement those changes.

When you start developing with low-code, you may continue to write overly detailed user stories and create more supporting documentation than is needed. This approach can extend the time devoted to backlog refinement and sprint planning because of the large quantity of information for the team to review and digest.

It will be challenging to continue this approach and keep up with the development velocity, so focusing on small, concise user stories, teams can reduce the time for backlog refinement and sprint planning (or increase the throughput of stories). Leverage the strong collaboration possible with low-code during development to further refine the stories.

Also, techniques like building your definition of ready criteria into the user story form in your agile project management tool can reduce lost cycles when missing criteria are discovered during refinement.

Because stories are developed quickly with low-code, teams should take a close look at the time devoted to estimates and reduce it where possible. Taking more time to refine estimates does not always result in higher accuracy estimates and takes away from the capacity to build and deploy software. If you’re not doing this already, consider using relative size estimation techniques like t-shirt sizing or planning poker with a Fibonacci sequence rather than hours.

Finally, mature agile teams using low-code can consider shortening their sprint durations to enable them to deliver valuable software to users faster than traditional platforms. You can tailor your project ceremonies, for example, if you move from two-week to one-week sprints, consider continuing to hold Retrospectives every two weeks.

As with everything in agile, you should experiment and see what works.

Effective Retrospectives

Taking the plunge to developing with low-code requires a commitment to accelerating your pace of continuous improvement. If you don’t regularly identify areas to improve and implement new approaches, you will hinder the speed and value from low-code. Be honest about the effectiveness of your retrospectives; if they aren’t working, do something about it. Talk to someone in your network or go online and look for a new game or exercise for a fresh look. Consider bringing in an outsider to facilitate the meeting, take the meeting off-site, or otherwise get the team out of its comfort zone.

How Do You Start?

Whether you are an agile and low-code veteran or just getting started, you are involved in an exciting practice. Recognize that you will need to work differently and adapt your current flavor of agile to keep pace with the accelerated development speed.

Start by looking closely at your backlog and how you manage it. Make sure you have strong product ownership, strong relationships with stakeholders, and a culture that makes decisions fast. Encourage and demand collaboration among all stakeholders, especially your project team. Actively anticipate, identify and resolve potential dependencies, especially with teams working in traditional development platforms. Finally, challenge your team to increase the efficiency and effectiveness of agile ceremonies to achieve maximum performance with low-code.

Agile and low-code are made for each other and open a ton of opportunities and possibilities for changing the way we build products. If you’re eager to begin, you can start by taking OutSystems for a spin. Have fun and enjoy the ride.