Introduction to Everyday Delivery

The ability to continually evolve is critical for your business and, therefore, your no-code app as well! Now that you’ve delivered the first release, this isn’t the end. In fact, this is just the beginning. It’s critical to follow up on the first go-live release with a disciplined approach to enable constant feature evolution. You don’t need to wait to batch your evolution into a big release. Ideally, your updates should be delivered to users as soon as they are ready. Response to user requests can be delivered in small, quick, incremental updates on a frequent basis — perhaps daily. In this chapter, we’re introducing the final phase: “Everyday Delivery.”

The Everyday Delivery Phase provides value delivery in small, quick, continual updates. This addresses some of the common challenges of traditional software development. Previously, software development projects often attempted to comprehensively document all requirements upfront and then spent months methodically building and testing each of the required features until the fully completed application was ready. This lifecycle is organized in sequential waves — analysis, design, coding, testing, and implementation. Hence, it is referred to as a “waterfall” approach. Waterfall lifecycles maximize the potential value to the stakeholder by saving up features into one big release (perhaps quarterly or annually). However, the risks of the final release delivery can be higher, and the sequential handoffs make it difficult to adapt to changes that may occur during the development releases. It also means that end users must sometimes wait a fairly lengthy period to receive enhancements they may have requested.

Agile methodologies for custom development have popularized taking a more incremental approach, whereby you break down larger releases into smaller releases of features. Depending on Agile’s flavor, each release’s duration varies. The Scrum version of Agile typically defines shorter “sprints” of two to three weeks in duration. However, not all sprints may be releasable to end users as the features built in each sprint may be a part of a broader user scenario that takes more time to fully complete. So, Agile can often lower delivery risks, improve quality, and also address the challenge of responding to changes since the team can adapt and change the plan during each sprint. However, it does not necessarily build out features any faster than traditional approaches. Users will usually get value delivered sooner, but they will still have to wait until the next sprint or iteration is complete.

Everyday Delivery builds on concepts from Agile but does not force you into a strictly defined release duration. Instead, you can release when you are ready and, ideally, as fast as you can. You can get feedback from your stakeholders and end users, and you can respond more quickly. Development is significantly accelerated thanks to the power of no-code capabilities. As a result, new features can be built and released more quickly. This creates an opportunity to release new micro use cases to end users in small incremental steps — ideally every single day.

Let’s examine in more detail what Everyday Delivery Phase actually looks like. As with the previous two phases, it is composed of four key stages. Each of these will be described more fully in the following chapters, but let’s briefly discuss the essential steps.

Stage 9 Feedback Collection

This stage ensures you have a model in place to collect regular feedback from your stakeholders and end users so that in later stages you can respond to their input quickly, systematically, and incrementally. We will provide guidance on how to adopt an approach that encompasses both user feedback (backed by data) and system feedback so that you aren’t letting your no-code team get too biased by “the squeaky wheel” or infrequent users. We will offer a brief review of some of the most common feedback collection techniques — from standard techniques like email surveys and focus groups to more advanced ones. We’ll review typical mistakes and suggest best practices on how to engage and interact with different groups.

Stage 10 Incremental Improvement

This stage starts with developing a constant stream of incremental improvements based on the feedback collected in the prior stage. We will discuss it using a five-step continuous improvement model to guide a systematic approach to developing the enhancements. Proper planning and definition are important to make sure the work is decomposed into small micro use cases. Once defined, the use cases will be developed through the continued use of Kanban to manage the stream of work. We’ll also discuss important considerations around software testing and governance that apply to this stage.

Stage 11 Everyday Delivery

This stage is all about delivering ongoing releases of functionality as soon as they are ready for deployment to end users. Unlike traditional waterfall or Scrum methodologies, the use of the Kanban Method promotes release when ready. We’ll outline the important components of the Everyday Delivery approach and offer key tips/practices. Properly defining and scoping enhancements into small, granular updates will help with both dependency management and conflict resolution. We’ll also discuss considerations to keep in mind when planning user rollout and enablement.

Stage 12 Application Audit

This final stage provides ongoing support and management for the developed no-code applications to ensure their optimal health and fitness over time. This stage includes a range of key activities including:

1. Auditing app performance to remove feature “bloat” and ensure proper usability and system responsiveness.

2. Auditing the app to watch out for obsolescence of specific features or even the end-of-life of the app.

3. Reviewing changes in the broader business process or organization that may require changes to the app.

4. Auditing for changes in internal or external governance requirements that may introduce changes into the governance processes of the application.

5. Reviewing app components to assess for opportunities to harvest functional or technical components that can be reused more broadly across other apps.

This is a lot to cover, but we’ll step through each of these stages in the following chapters, along with guidance, examples, and practical tips that can be used at each step along the way.