19
Stage 11
Everyday Delivery
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”
One of the key principles behind Agile is the notion of continuous delivery of value. Yet, too often in traditional software development, we get stuck in having to conform to defined release sprints or iterations. A key differentiation of the no-code approach is accelerated time-to-market. The modern platform capabilities empower no-code teams to deliver sufficient outcomes daily to end users.
The spirit of the Everyday Delivery stage is striving to provide rapid updates to the end user and maintaining a high velocity and ongoing improvement cycle. The deployment can be based on a specific feature or set of features without a need to connect it to a specific sprint deadline or other formal milestones. To establish this mode of continuous delivery, it’s critical to appropriately decompose and scope your work items so that you can rely on the higher degree of deployment automation provided by no-code platforms. This allows for quick, small updates to be pushed to production frequently (perhaps daily) while maintaining higher levels of quality than traditional “big bang” software releases.
Let’s dive into discussing the Everyday Delivery stage by defining what it is and what you should focus on at this stage.
Defining Everyday Delivery
As the name implies, the goal of the Everyday Delivery stage is to deliver value “every day.” At first, this may seem obvious — isn’t delivering value the goal of any software development team? Ideally, yes, but we all know it can be incredibly difficult to release enhancements daily, especially when using traditional software development methods. Delivering value at speed requires a fundamentally different approach. But once you adopt the approach that allows daily enhancements, you’ll see how it results in incredible advantages, including the ability to change and innovate at a whole new level.
Components of Everyday Delivery
Let’s start understanding the common elements that enable this breakthrough release strategy:
No-code tools
As might be expected, no-code tools are at the foundation of the Everyday Delivery strategy. No matter how powerful traditional custom development tools are, just the act of writing custom code means that daily releases are unlikely (lower-level coding and unit testing alone impedes this pace of delivery). So, the speed and productivity you receive from no-code tools facilitate this rapid Everyday Delivery approach.
Continuous deployment
In Chapter 15 (First Release), we initially introduced the approach of fully automating the movement of no-code applications across environments and into production. This remains key to Everyday Delivery as any manual steps in the deployment process will result in additional time, effort, and risk.
Fast rollback
A “rollback” is the ability to revert an environment to an earlier known state if you find that a change is not working as expected. This allows you to undo a problematic set of updates so that users can continue using the application as it was previously. At the same time, you troubleshoot and correct whatever problem was introduced. Rollback can typically be addressed either by the deployment automation in the no-code platform (if it can undo or reverse deployments) or possibly through a dedicated staging environment (mirroring the last production environment before a change is being released). Fast rollback gives you the confidence to move quickly in the Everyday Delivery approach because you know you can always return to an earlier configuration if needed.
Best practice tip:
Here are additional tips and practices for establishing the Everyday Delivery approach.
Appropriate definition and scoping are essential.
It’s difficult to maintain a speed of release if the scope of your features is large and cross-dependent on many other features. Focus on micro use cases that can be deployed almost immediately.
Make sure you’re factoring in other dependencies.
You need to consider whether other teams are developing components or related features that your application will need and plan accordingly. For example, suppose your feature is ready for delivery and the other remaining features are not done yet. In that case, the team needs to find a way to separate incomplete features (so they can be delivered in the future) and focus on deploying the completed ones.
Use the Kanban Method to track micro use cases.
Using Kanban (explained in Chapter 11) gives you fine-grained control and visibility over the work as it flows through the team. It also provides more flexibility in choosing when to release — Kanban does not enforce a set amount of time required for a release. Each team can release value as soon as they are ready.
When delivering features, follow the same sequence and engage the same set of checks and environments as you did during the Go-Live Phase.
Just because you are moving fast does not mean you get to skip steps! As outlined in the previous chapter, the use of appropriate software testing and governance checks are still required to have confidence in the release.
It’s important to remember that Everyday Delivery means users will see changes to the app more frequently. Thus, you should train and enable current users on new features and workflows. Be sure to communicate any impact that updates may have. Here are some user rollout considerations:
-
The no-code team should continuously update and retrain end users on the newly-delivered capabilities. It is recommended that you establish a consistent and engaging process for informing and training users on these changes. Avoid overreliance on email, which can be missed or not read as new users join the organization.
-
The new feature changes can fall into one of the following categories:
-
System changes/invisible changes (usually don’t require informing/training).
-
Changes that are intuitively understandable (require minimal informing/training).
-
Drastic changes that impact the flow and experience (require an effort for informing/training).
-
-
These first two categories may require updates via prompts within the app. More drastic changes that require understanding a new flow or experience should be assessed and enablement as necessary. This could range from a short video demo to in-person instruction.
-
The release of a new feature should be in sync with the overall end user experience and impact on their process. Don’t change the app before instituting any released process changes (or vice versa). All the changes should be coordinated to be rolled out together, along with applicable user enablement.
-
Scoping of feature size is key here as well. Smaller “bite-sized” updates are typically easier for users to consume and lessen the change management impact. Consider aligning more significant changes into batches where user enablement and process changes can be rolled out.
Final Takeaways
No-code platforms offer the opportunity to adopt a model of Everyday Delivery — allowing you to deliver features to your end users daily. This increases user satisfaction (by consistently and rapidly responding to their feedback) and improves user adoption (by reducing the impact of massive changes, instead introducing a smaller set of more easily adopted updates). However, it’s important to correctly scope and decompose for a successful release and apply the right model for managing user enablement and rollout.
Now, we’re nearly done — we’re about to finish off the No-code Lifecycle with the final stage: The Application Audit stage.