Agile Process: Why You Need Feedback Loops During & After Sprints

gowebing

For the uninitiated, the agile process is an iterative, incremental, and collaborative approach to software development. The goal is to satisfy business stakeholders, or external customers and partners, through early and continuous delivery of working software that provides the anticipated business value and user benefits.

As part of its focus on enabling close collaboration between IT and the business, the agile process emphasizes short feedback loops. Frequent feedback from business stakeholders and end users keeps the development team focused on the solution's intended goals and helps ensure they deliver high-value features. Equally important, feedback loops allow the team to accommodate change later in the development process, particularly as new or refined requirements emerge.

That's why the agile process itself has built-in checkpoints to facilitate feedback and collaboration. For starters, the daily standup allows members of the development team to share status updates and identify obstacles standing in their way. The sprint review meeting is an opportunity to present a shippable increment of software to a broader group, including the product owner, management, and end users. In addition to assessing the project against the sprint goals, the group can provide feedback on the current solution and as-yet-unmet needs that is fed into the next sprint planning meeting. Lastly, there's the project retrospective, which allows the development team to look back at what went well and what could be done better in future agile projects.

Waiting Until the End of the Sprint for Feedback is Too Long

While this is all well and good, I'd argue that waiting until even the end of a sprint is too long to solicit feedback, particularly from business stakeholders and end users. That's because software development is an embodiment of the butterfly effect, where, especially early in the development process, minor changes can result in large differences downstream. This is particularly true for applications with unclear or changing requirements. Without the opportunity to discuss and validate users' needs early and often, developers will inevitably make assumptions that, unchecked, could steer the solution off course, and become increasingly harder to unravel the later in the process you get.

Thus, while agile teams typically understand the importance of collecting feedback after a sprint is complete, they should also be thinking about how to collect feedback while building their shippable iteration. As Henrik Kniberg and Mattias Skarin wrote in their book Kanban and Scrum: Making the Most of Both:

"Generally speaking, you want as short a feedback loop as possible, so you can adapt your process quickly."

The challenge is that while working software can be reviewed at the sprint review meeting, that's typically not possible while the software is being built. And in the absence of working software, the only representation of what is being built is the code itself. Here's the thing, though: have you ever seen a developer sit with an end user and review a piece of Java or .NET code as a means of validating whether the right functionality is being built? Probably not, because 3GL programming languages simply aren't readily accessible to, and understood by, business users.

Leveraging a Common Visual Language to Shrink Feedback Loops

To enable short feedback loops both during and after sprints, agile teams need a common language that creates mutual understanding between the development team and the business and facilitates constant communication and collaboration to ensure that the right solution is being built.

One approach that's gaining traction in the enterprise is low-code app development. Low-code platforms employ visual, model-driven development techniques for defining an application's user interfaces, data model, and logic. Because these visual models are easily understood by the entire team, they facilitate frequent, ongoing collaboration between developers and the business. At any point—even early in the development process—they can sit together to discuss and review functionality to gather feedback, validate assumptions, and identify improvements. In many cases, application changes stemming from feedback can be implemented on the spot, and the updated application re-deployed for instant validation!

For instance, Texas Life is using Mendix's low-code platform to execute on its digital transformation strategy by digitizing workflows, re-writing legacy applications and creating self-service portals for customers and brokers. According to Brad Kendrick, Vice President of IT at Texas Life, the value of a low-code platform is that it enables iterative, collaborative development. "The developer and a business person can sit together, bounce ideas off each other, build workflows, design and easily hone applications on-screen—innovating without getting stalled by technical detail," he says.

Embedding Business-IT Collaboration in Each Step of the App Lifecycle

While virtually every low-code platform employs visual development techniques, fewer have been architected from the ground up to embed business-IT collaboration in each step of the application lifecycle. Thus, in addition to leveraging visual models as a common language, the following capabilities help facilitate short feedback loops and ongoing collaboration:

While the agile process itself was a major step forward in shortening feedback loops from several months to two weeks (or whatever the sprint duration is), enterprises under pressure to deliver high-value applications in support of digital transformation strategies need more frequent feedback and collaboration. Low-code platforms literally shrink feedback loops down to near real time, helping to ensure the development team delivers a solution that meets both user needs and business objectives.


This article was originally published on the Mendix blog. 

 

 

 

 

Top