Feedback Loop

This Toolkit for Feedback Loop provides example checklists and questions to help you support the delivery of MVP as quickly as possible, through collecting continuous feedback that helps you ensure alignment and helps you stay focused and on track for the Go-Live of your initial release. We will also get further into some tips and practices for managing this process and ensuring effective change management. This feedback collection actually runs concurrently with the prior ‘Prototype-to-MVP’ stage (Chapter 12). Refer also to the supporting material around both the key Roles and Responsibilities (Chapter 4) and Application Matrix (Chapter 5), which will be referenced throughout the guidance.

The outcome of this stage should be a validated end-to-end, no-code app ready to begin final governance checks and release go-live activities (which will be addressed in later stages).

The primary inputs to this stage are as follows:

• No-code Application: The primary input to this stage is the no-code app itself. The Prototype to MVP stage is happening concurrently and will be producing frequent updated releases of the no-code app which can be frequently shown to stakeholders. As the no-code team works on individual features from the MVP inventory, they can typically be built much more immediately and incrementally on top of the existing app prototype; this means there does not have to be lengthy delays in waiting for a reviewable version of the app, since as new features are added you can usually publish the working prototype for quick reviewer feedback. This will allow the opportunity for a much more immediate and continuous feedback cycle throughout the building process.

• Work management processes (e.g. Kanban) defined and team enabled: The Kanban framework is not only used by the No-code development team to manage their building of the app, but also provides a highly effective means of communicating to stakeholders. The Kanban Method is all about promoting transparency, encouraging feedback, and holding regular review meetings, making it ideal for Feedback Loop activities since your stakeholder will have full visibility of the work being reviewed and where it fits within the broader MVP scope. Make sure your No-code stakeholders, and any other power users/SMEs that may be providing feedback, have been enabled with access to your Kanban boards.

• Scope and Change Management processes in place: Finally, as you collect feedback it is essential to apply rigorous scope and change management. It is essential these processes were established in order to stay disciplined and not lose sight of shipping what is essential for MVP.

It’s important to start with selecting both the most effective and also the right number of stakeholders to include in the feedback process. If you identify the wrong stakeholders (those who lack the right domain knowledge or perhaps are not empowered to make decisions), you can waste a lot of the team’s time. Too many stakeholders also create challenges given the complexity of reconciling user feedback increasing geometrically. So, if possible, avoid having extended teams of stakeholders to define and approve the scope as this usually leads to a more complicated process and an extended timeline.

Identifying and Selecting Stakeholders

Determine who the main stakeholder(s) are for your project. These could be project sponsors, decision-makers, or other individuals or groups affected by or involved in the project. It’s recommended to minimize the number of stakeholders involved in the MVP. Ideally, you’d nominate a single stakeholder/decision-maker who would represent the user population. This will streamline the decisions and prioritization of scope during both the initial MVP and also during the ongoing feedback prioritization. The stakeholder you select should have a good understanding of the business process and have sufficient authority to make decisions related to the functionality. While the stakeholder does not need to be deeply technical, they should understand technology and its ability to impact the business. Understand their interests and needs. Take the time to understand the interests, needs, and expectations of each stakeholder. This will help you tailor your communication and engagement strategies accordingly. If you do have more than one stakeholder, assess the level of influence and impact each stakeholder has on your project. Prioritize stakeholders based on their importance and involvement in the project and allocate appropriate time and resources for engagement. Note that while you may limit the number of official stakeholders, it is highly recommended to include users from related/impacted functional areas directly on the no-code development team. This provides a way to properly embed a lot of practical and operational knowledge of the business function into the no-code development itself, ultimately improving quality and increasing the odds of better alignment with the no-code stakeholder. Avoid the ‘squeaky wheel’ syndrome where the loudest users/ stakeholders overwhelm others resulting in biased priorities or decisions. We will explore this further in Stage 9 (Feedback Collection).

Engaging Stakeholders

Create a clear communication plan that outlines how you will engage with stakeholders throughout the project. This plan should include the frequency and channels of communication, as well as the types of information to be shared. Customize your communication approach to suit your stakeholder's preferences and needs. Some may prefer face-to-face meetings, while others may prefer email updates or online collaboration tools. Adapt your communication style accordingly. Regularly update stakeholders on the progress of your no-code development (using tools such as the Kanban method discussed earlier). Be transparent about successes, challenges, and any changes to timelines or scope. Clear communication builds trust and keeps stakeholders engaged. Set realistic expectations with stakeholders regarding what the no-code MVP release can deliver and within what timeframe. Be transparent about limitations and potential risks and manage any misconceptions or overblown expectations. Acknowledge the contributions and efforts of stakeholders involved in your project. Publicly recognize their input and thank them for their involvement. This fosters a positive relationship and encourages continued engagement.

Remember that stakeholder engagement is an ongoing process. Regularly review and reassess your engagement strategies to ensure they remain effective and aligned with stakeholder needs throughout the duration of your no-code project.

The building of the no-code app was largely addressed in the Prototype to MVP stage, so we leave the ‘Build’ aspect described there and now focus on the ‘Review’ activities.

Since building the no-code app can be done highly incrementally as you add new features into the application, this allows you to ‘work in’ review sessions throughout development. Reviews with your no-code stakeholder to demo the current version of the prototype can be performed on a completed workflow or feature without a need to wait for either MVP or sprint completion, which is the case for Scrum. As soon as the use case/features are completed to a point they can be demonstrated, you can start to collect feedback in parallel with continuing development in other areas.

You will want to actively and frequently solicit input and feedback from stakeholders. Generally, you should plan for review sessions at least a few times per week to keep up with the needed pace of no-code development. The session should focus on reviewing the prototype and discussing business requirements for mini use cases. This should be done in small(er) reviews, as the no-code app progress can be showed early and often (in contrast to traditional development). Consider scheduling a regular standup that occurs multiple times a week if possible. Incorporate their suggestions and address their concerns to create a sense of collaboration.

Now, the timing of review sessions may vary slightly based on your Delivery Model:

• For simple projects under a ‘DIY’ Delivery model, given the speed of performing No-code feature development ‘on the fly’ and the feedback received after the demo can be implemented also very fast. In this sense, it will look like a more linear process (as you continue to iterate based on feedback).

• For the more complex projects (CoE and Fusion Team models) there may be portions of the solution that include custom development by professional developers. In this case, the process of the feedback gathering for these components might be linked to the ceremonies under the selected SDLС framework (e.g. Scrum, with a Demo usually performed at the end of each Sprint). In such cases, you should refer to the ‘complete’ micro use cases as a scope of the demo. This allows you to avoid the frustration of the stakeholders if some part of the solution is not developed completely yet.

In any case, all feedback received during the demo should be noted and stored in some visible and tracked view: meeting notes, Change Requests log, User Stories etc. It is important to capture and track the history of the changes requested and assure them that all requests are processed (regardless of the final decision – implement/not to implement).

The following is an example of a typical Change Requests log:

Note, the setting of the fields around Estimation/Impact, Priority, and Status may not yet be known during the reviews, as they will be addressed in the following sections. That’s okay – for now just capture the stakeholder feedback and ensure it is not lost.

The success of the Feedback Loop stage lies in constant collaboration between the no-code team and stakeholders. If you follow the guidance outlined in the prior sections, it’s possible to collect large amounts of feedback and tweak the current no-code app almost immediately with these capabilities to gain alignment and progress with the development.

That said, as you progress, it’s also essential to stay focused on the MVP and not veer too far off track. This means you must triage and prioritize any new requests for capabilities that arise during the feedback sessions with the same approach you used to define the MVP. If something is critical to the MVP and can be accommodated inline, then it’s best to address it immediately. However, all requirements that have not been included in the MVP should be placed into the post-MVP improvement backlog that will be reviewed and processed in the Incremental Improvement stage.

Triage of the identified feedback can also be based on the complexity of the requested changes. Here we suggest some guidance using the following decision matrix related to the ‘size’ of the request.

• If the request is small and related to the ‘finetuning’ of the developed application, then the no-code platform allows you to implement them very rapidly, and such requests should be processed almost immediately (e.g. – UI changes to the fields placement, colors of the screens, fonts, hints etc.)

• If the request is just fulfilling the business logic and simplification of the UX part, then try to process these ASAP. However, these requests may require more effort (based upon your T-shirt sizing) and for medium/large items it’s important to consider the capacity of the team or future load. (e.g. – additional business logic on the data processing with some filtration behind)

• If the request is related to new/additional business logic requested – on top of the developed solution – this reflects a change to MVP scope. This may require changes to design or even the overall architecture and should be carefully reviewed. Such types of requests are usually treated as Change Requests and can be processed under a Change Management process (outlined below in the ‘Address Feedback’ section).

• If the request reflects ‘Core’ changes to the scope, this will have significant impact. It might be the case that the owner or stakeholders discover fundamental needs for the application which are in contradiction with the initial business use case; in this case the developed solution may not address the majority of the business needs. (e.g. company decided to switch from hard copies of the documents to the electronic format, and your application wasn’t developed to be integrated with a such provider of the services). In such cases, you might need to ‘pause’ the application building and return back to the initial stages of the project.

Note, a separate process and criteria for Triage is usually needed for Medium and Advanced projects, where the developed solution can’t be changed ‘on the fly’ and it might require consolidation of efforts of the involved parties, which is not always so simple as stated due to time constraints, budget constraints, capacity constraints etc.

After the Triage step, you’ve clearly identified the requests related to new/additional business logic and formally identified them as change requests (CRs). This step now helps you carefully track and manage the flow of all CRs as they progress through the development process. We will address this as three sub-activities: Analysis, Estimation, and Decision.

Analysis	The Triage step will have performed an initial high-level T-shirt sizing for each CR based upon assumptions on relative complexity. However, it’s recommended to perform a next level of analysis as the No-code development team begins to pick up and confirm the work. This will reuse much of the same process as described in Stage 4 (Project Assignment), for T-shirt sizing; and possibly even returning to Stage 2 (Options analysis), for more significant change requests that may impact the overall solution architecture. During this next level analysis, you should engage the process and domain experts who are closest to the business process and can help validate the full level of complexity. For more technically complex CRs, you should involve additional architects or professional development resources (from the Fusion Team or CoE), as needed to assess the complexity. The final result of the Analysis step is the confirmed estimation of the complexity and deeper analysis needed to support estimation.
Estimation	This will reuse much of the same process as described in Stage 4 (Project Assignment), for estimation of effort and schedule, using either the rubrics provided for standard estimation or ideally factors from your team’s experience from prior development efforts. For more technically complex CRs, you should involve additional architects or professional development resources (from the Fusion Team or CoE), as needed to estimate the effort. Keep in mind this may be based around a selected SDLС framework (e.g. Scrum) or may be dependent upon their planned release schedules.
Decision	The final important step is usually performed with the deep involvement of the owner – based on the highlighted constraints and provided estimation, one of the following decisions can be made: Include CR into MVP scope Include CR into Post-MVP scope Replace part of MVP scope with the new CR Refusal of the CR (either complete or transferring it into the general backlog for later consideration) In any case, this decision should be tracked and reflected in the Change Requests Log.

• Be prepared to be disciplined about managing scope based upon the MVP approach:

  • ‘E2E Process’: While you may have started with a focus on ‘happy path’, it is easy for exceptions and edge cases to be brought up as feedback from stakeholders/users, so be sure to flag these for the backlog and manage them as post MVP CRs. Remind all stakeholders of the importance of staying focused on initial speed to MVP delivery.

  • ‘Complete Workflow’: It's also not uncommon to have the targeted workflow start to expand with greater breadth as feedback identifies the parts of the process that were omitted; again, remind stakeholders of the importance of staying disciplined on MVP focusing on just the essential workflow.

• Establish a well-defined and documented process for submitting, reviewing, and approving change requests. This process should be communicated to all stakeholders involved.

• It is recommended to implement a centralized system or platform to manage change requests. This could be a project management tool or a dedicated change management software, or it could be as simple as a shared spreadsheet.

• Create standardized templates for change requests that capture essential information such as the reason for the change, expected outcomes, and impact on existing functionality. This ensures all required information is consistently captured.

• Clearly communicate the criteria and guidelines for submitting change requests. Specify the required information and any supporting documentation needed to evaluate the change.

• Assign a designated owner to each change request. This person will be responsible for reviewing, prioritizing, and coordinating the necessary actions to address the request.

• Define/Establish a mechanism for prioritizing change requests. It may be typically based on factors such as urgency, impact on project goals, and available resources. This ensures high-priority changes are addressed promptly. There are a variety of common prioritization frameworks that can be adopted – we discuss use of the ‘MoSCoW’ framework in more detail in Incremental Improvements (Chapter 18), but it can also be used to help prioritize pre- MVP CRs.

• In addition to effort, make sure to assess the feasibility and impact of each change request before approving it. Consider factors such as resource availability (based upon calendars, assigned workloads, etc), technical constraints, and potential risks.

• Communication is key - keep stakeholders informed about the status of change requests and their implementation progress. Regularly communicate updates, timelines, and any adjustments made along the way.

• Maintain a comprehensive record of all change requests, including their details, approvals, and outcomes. Conduct periodic reviews of the change request process to identify areas for improvement and make necessary adjustments.

• Finally, consider the CR log is a ‘living’ document that will be maintained until MVP to track and validate successful delivery. Before deploying MVP to the production environment, it is recommended to revalidate that the CR still works. This helps identify any issues or conflicts that may arise when multiple CRs or features are combined together.