Skip to main content

Fast Feedback

Feedback is important. In fact feedback is what helps us improve and enables us to make informed decisions at the correct time. For example imagine you are driving a car in icy weather and the steering goes light. This feedback tells you that you need to take action as it is likely your car has started to slide. So feedback can help us take action to keep us safe and without it the human race would still be stuck in the dark ages.


Now typically you will be asked for feedback in the following types of situations:


  • Feedback on a training course

  • Feedback on colleges for the appraisal process


However, there is more to feedback than that.


This post will talk about why feedback is important, the effects of slow feedback and how if this feedback was quicker how it would lead to better outcomes.


What is feedback?

Here’s the definition from Wikpedia:


“information about reactions to a product, a person's performance of a task, etc. which is used as a basis for improvement.”


So feedback is all about enabling improvement. Without feedback you would have no idea that you need to improve. 

Types of Feedback

There are different types of feedback. Here are some examples:

  • Feedback within a team

    • This feedback is with the context of a team. For example feedback between developers and testers

  • Feedback with stakeholders

    • This feedback is not with your immediate team but feedback with thee users and the people that have a vested interest in the software that you are working on.

  • Non Human Feedback

    • This is feedback from “machine’ so things like:

      • Feedback from log files about user behaviour

      • Feedback from test automation suites

Why is feedback important in software development?

Feedback is important for the following reasons:

  • Helps others make decisions

    • The feedback we give can help others in the team/business make decisions. For example, your feedback on the state of testing a feature. The Project Manager can use this to decide whether to ask for more time to get a feature delivered.

  • Helps people understand what is going on 

    • The feedback we give can give visibility as to what is happening to other members of the team/business. For example a CI can spit out to a chat program whether it has passed or failed. This gives all members of the team visibility of the current state of the CI for a particular feature

  • Shares Knowledge

    • The feedback we give can build people's knowledge. For example if you have a meeting with a product owner and they feedback on some aspects of how the users use the system, you can provide this as  feedback to the rest of the team. This will  enhance their knowledge of the system and the people that use it.

  • Helps teams and individuals improve

    • The feedback we give can help teams and individuals improve. For example when performing a code review you can give feedback on areas of the code that could be made more efficient. That will help the developer improve their coding skills. At a team level, the feedback you give in a retrospective can be used to help the entire team improve. 

Impact of slow feedback

Slow feedback can be a real hindrance to teams in creating valuable features to users quickly and efficiently. Some examples of the impact of slow feedback are:

  • Slower releases

    • Releases not getting out to customers on time because there is uncertainty about the functionality being correct.

  • Bug fixes take longer to resolve

    • Clients waiting longer for bug fixes due to the long lead time from bug being raised to being fixed.

  • Changes to features take longer to implement

    • Key market changing features being delayed due to lack of clarity and understanding from the development team.

  • Users stop using the system

    • Users getting frustrated when the system provides what appears to be incorrect information.


The list can go on and on, so it’s important that feedback is quick.

Impact of fast feedback

Fast feedback is critical in software development, whether it be in a waterfall environment or agile. The quicker people (or anything for that matter) can get feedback the quicker whatever is consuming that feedback can act and improve. In modern software development and business this is essential in order to be successful. 

So looking at the examples of slow feedback above, how could fast feedback have changed them? Below are some examples…

  • Slower releases

    • If the CI build was running quickly and therefore giving fast feedback to the team about the tests, then a release could be pushed to production quicker.

  • Bug fixes take longer to resolve

    • If there was fast feedback between the tester and the developer the tester could give the developer all of the information they need quickly so they can start fixing the issue sooner. 

  • Changes to features take longer to implement

    • If there was fast feedback from the product owner about a prototype then the team could understand exactly what was required and changes can be implemented and in the users hands sooner.

  • Users stop using the system

    • If feedback to users was quick they may have a better understanding of the system and why it is doing what t is doing and not stop using it all together.

Summary

So as you can see, fast feedback is essential in modern software delivery teams across the 3 types of feedback. Without fast feedback we cannot learn, improve and quickly pivot should we need to. Understanding how to identify these areas and how to resolve them is the next challenge….. 

Comments

Popular posts from this blog

How to deal with pauses and timeouts in specflow

So this blogpost is in response to the weekly Specflow blog posts and challenges that have been written by Gojko Adzic. This weeks challenge was how would you rewrite or rephrase the below scenario: Given a user registers successfully When the account page reloads And the user waits 2 seconds Then the account page displays "Account approved" My initial though was something like this: Given a user registers successfully  When the account page reloads   Then the account page is displayed within a satisfactory time period     And the account page displays "Account Approved" Now the problem with this scenario is what defines a satisfactory time? You could add it as a comment or in a scenario outline but over time the time a user waits could change and if this is updated in the code behind but the scenario outline or comments are not, then what the test does and what is described do not match - this would potentially cause issues in the future. My next ide

Testing and Mindfulness

How aware are you? Do you live in the here and now or is your mind always somewhere else? This blog post is about Mindfulness. Mindfulness is a simple meditation and is defined as (According to Wikipedia): "The intentional, accepting and non-judgemental focus of one's attention on the emotions, thoughts and sensations occurring in the present moment" Now Mindfulness has become more popular in the west in recent years as it has shown to have benefits for people who are suffering from Depression and Anxiety. It has been around for a while and is often thought to of originated from Buddhism and some people believe it started thousands of years ago. Now modern life is hectic and I’m sure we all have lots of things going on in our lives that keep our Brains busy and trying to focus on one thing at a time can be a challenge. I can't remember the number of times I've been doing something and my mind is somewhere else entirely. Mindfulness helps you focus on

Building a test strategy for a new team

Teams, we have all been on them. Some are good and some are bad. Some we never wanted to leave and others we probably couldn't wait to leave. Now most of the time (well in my experience anyway) you tend to get put into a team that already exists. Maybe you are a new hire or maybe you have asked to change to a different product team.  When you do this, more than likely there will already be a testing strategy in place. It may be that you adapt it and change it in any way you see fit to improve the testing. But imagine if everyone on the team was new? How would you decide your testing strategy? This post will go through some useful things you can do to help a new team develop a test strategy. Table of Contents ๐Ÿ“ˆ What is a Test Strategy? ๐Ÿค” Where should I start? ๐ŸŽฏ Understand the company and their goals ๐Ÿ’ช Play to the teams strengths ๐Ÿ‘️‍๐Ÿ—จ️ Understand what quality looks like ๐Ÿ“ Understand Scope ๐Ÿงช Understand the type of tests you need ๐Ÿ“Š Measure your success ๐Ÿค Collaborate ๐Ÿ“ Summar