Feedback & Rapid Prototyping

“No fixed direction remains valid for long” - Extreme Programming Explained by Kent Beck

Our teams strive to generate as much feedback as we can handle, as quickly as possible. We try to shorten the feedback cycle to minutes or hours, instead of weeks or months. The sooner we know, the sooner we can adapt our course to the one that provides the most value to our clients. Feedback comes to us in many flavors. It can be internal feedback on our code while pair programming, feedback from the client during an iteration demo or inputs from an end-user through a user interview. These are all intrinsic and invaluable to our process.

How we do it?

To build a new product, new feature, or new solution, we start with an intensive prototyping phase. Here we make assumptions, we present mockups, we validate or invalidate our understanding and we iterate quickly to arrive at optimal solutions. This way, as a team, we have a clear indicator of whether we’re moving in the right or wrong direction before we write a single line of code.

As we start implementation, we do client demos with every iteration to make sure we are aligned on all fronts including feature prioritization, solution efficacy and end business goals. And not limiting feedback to being just customer facing, our team thrives on feedback from within. There are no hierarchies and no lines that should not be crossed. From pointers on how best to use IDE shortcuts, to clean coding practices, to pointing out bad pronunciations! We don’t refrain from speaking up and love getting tips ourselves.

Our goal is to help our clients’ business prosper by accommodating ever-changing requirements in fast-moving and constantly evolving environments. We cherish constant feedback and respond to it by course-correction and exercising agility in the real sense as and when required - quickly.