Staying on Course Through Continuous Feedback


Staying on Course Through Continuous Feedback

What if on a casual sunny afternoon trip down the M25, the driver in a vehicle in front of you suddenly decided to hold his steering wheel tightly in place and ignore everything his eyes were telling him about the road ahead? If you were lucky enough to not be caught off guard, you would soon find yourself witnessing a senseless car crash. Albeit substantially less tragic, this is very similar to what happens when development teams go about their business without adequately paying heed to customer feedback. Eventually, they are bound to veer dramatically off course, and cause others to suffer the results of their recklessness.

Unfortunately, the same is often true even when software companies follow established development methods. The popular waterfall model, for example, scopes out requirements only at the start of a project. As a result, once initial feedback is received and a path has been determined, there is no turning back. Most software engineers will be either unable or unwilling to make any changes to a project.

The situation is not made any better when dealing with remote teams, as the distance factor quickly takes its toll on customers and a lack of feedback can be extremely off-putting. With our development centres based in Ukraine, this is something that is particularly concerning to SPG. Consequently, we have spent a great deal of time devising the best approach to creating a wholly transparent development process — at one point even considering live cameras in our offices!

The final result of our efforts, however, is our own rendition of what Agile calls continuous feedback. This is how SPG are able to ensure that the performance of our teams and evolution of our projects will always be kept on an upward trajectory. The process itself is simple — at each phase of development, we pursue the full involvement of our customers in order to gather their ideas and suggestions. At the same time, seeking complete openness, we make tools available to our clients that aim to keep them fully informed on the status of their projects.

It is important to note that although continuous feedback may conjure images of a flooded inbox, the key term here is transparency, not information overload. Accordingly, instead of relying on countless email updates, we provide all our customers with access to convenient task-tracking systems that enable them to view the progress being made on each assignment, at any moment of their choosing. In fact, because our time-tracking applications are used at the individual level, customers are even able to find out what each developer has been up to, as well as their previous tasks on any given date. In this way, we keep the available data both complete and unobtrusive.

Likewise, due to the iterative nature of our development process, SPG also strive to involve customers in every Sprint planning meeting. In addition to giving businesses a platform to express their concerns, this allows us to keep requirements in close alignment with our clients’ expectations.

By promoting a culture of continuous feedback, Software Planet Group have found that even development teams stand to gain, as they are able to quickly identify faults in their performance and find new ways to improve the quality of their work. Thus, in stark contrast to other companies whose rigid feedback policies often result in an ill-fated shipwreck, we view customer input as a guiding compass, whose insight and direction are essential to delivering quality software with real value. 

Related Stories

Git as the core of the dev process illustration
November 13, 2020

Git as the Core of the Development Process

How exactly do we manage our source code with Git and how does the Gitflow branching model fit into our customers' version control processes? Read on!

Project success cover
Integrating New Arrivals
October 16, 2018

Integrating New Arrivals

Our customers often inquire as to how in the world our newer developers will be skilful enough to deal with our development process — and really, who can blame then?