Reader small image

You're reading from  Implementing Azure DevOps Solutions

Product typeBook
Published inJun 2020
PublisherPackt
ISBN-139781789619690
Edition1st Edition
Tools
Concepts
Right arrow
Authors (2):
Henry Been
Henry Been
author image
Henry Been

Henry Been has been working in IT for over ten years. He is an independent architect, developer, and trainer in a number of companies. With many of these companies, he has embarked on a journey implementing practices such as continuous integration and deployment, infrastructure as code, trunk-based development, and implementing feedback loops. Alongside his work, he creates online training courses for A Cloud Guru, and frequently speaks at meetups and conferences. He was awarded the Microsoft MVP award in 2019.
Read more about Henry Been

Maik van der Gaag
Maik van der Gaag
author image
Maik van der Gaag

Maik van der Gaag is an architect and trainer at 3fifty, an experienced consultancy company with a strong focus on the Microsoft cloud. He has over 15 years' experience of providing architecture, development, training, and design expertise. During his career, he has worked on a variety of projects, ranging from cloud transformations to DevOps implementations. He loves to share his knowledge, which was also one of the reasons why he founded the Dutch Cloud meetup. Maik is a public speaker, writes blogs, and organizes events.
Read more about Maik van der Gaag

View More author details
Right arrow

Gathering User Feedback

In the previous chapter, you learned how to measure how your applications are performing in production. You learned how to gather crash reports and logs and how to instrument an application. However, the purpose of software is not just to deliver perfectly running applications, but to create business value. Gathering user feedback is necessary to determine whether your application is also achieving this higher goal. In this chapter, you will learn techniques to measure whether your users are satisfied, which features they are using and which they are not, and how you can use this information to steer future developments.

To do this, this chapter starts by introducing the concept of continuous feedback. Next, it moves on to introduce different approaches to asking users for feedback and recording their responses. This can be both in-application or via other...

Technical requirements

There are no technical requirements for this chapter.

Understanding continuous feedback

As explained in Chapter 1, Introduction to DevOps, DevOps is a cultural movement that tries to bring developers and operators closer together, to help them to deliver business value faster and more reliable. Feedback loops are an important element in doing this. In the previous chapter, we saw numerous feedback loops:

  • Developers can run unit tests on their local machine to verify that their changes did not break existing behaviors.
  • After source code check in, all unit tests are run again and a pipeline with more tests starts running.
  • Besides functional tests, security tests and dependency scans can be run.
  • After releasing, logs and metrics are gathered to determine whether the application is running smoothly.

All of this provides feedback on the technical quality of the work and now it is time to add one more feedback loop—a loop intended...

Asking for direct feedback

One very straightforward way to collect user feedback is by just asking for it. Over the last few years, more and more applications have been enriched with feedback mechanisms built into the application. Other approaches that are commonly used are publishing a public roadmap and engaging with customers directly.

Advantages of in-product feedback

Collecting feedback in-product is a good way to get started with direct user feedback. Examples of in-product feedback are grading a specific view or action, giving a thumbs up or down, or sending a happy or sad smiley face.

Collecting in-product feedback has the following advantages:

  • It is one of the easiest ways for customers to give feedback, taking virtually...

Gathering indirect feedback

A well known saying in software development is that users do not know what they want. While this may sound harsh, there are a few reasons why direct user feedback from discussions, interviews, and focus groups does not necessarily lead to good product feedback:

  • One reason for this is that everyone wants to be liked. When conducting an interview, or talking to a group of users, there is a chance that they will only say what they believe the interviewer wants to hear.
  • It has a high turn-around time. Scheduling interviews and focus groups takes time and finding a time that everyone can attend can easily take days or even weeks.
  • It is hard to keep asking the same group of users for feedback every few weeks. This is especially important when trying to determine whether the quality of a feature is improving with the newest updates or not.

For these reasons...

Implementing hypothesis-driven development

A risk in software development is that teams are so busy creating more and more features that they forget to reflect upon their business value while everyone knows that not every feature is a success. Some features may not be used at all or may even be disliked by users. As an industry, we have come to learn that product owners have a hard time predicting which features will be really liked by users and which will not. Even when using all of the feedback mechanisms discussed previously, predicting what users want is difficult.

Another important thing to recognize is that every feature in the product also brings a future cost. Every feature requires documentation, support, and maintenance. This means that unnecessary features are driving costs up as well. From this stance, it makes sense to not only leave non-value features but to even...

Summary

In this chapter, you learned how to measure the business outcomes of software development activities. First, you learned about the importance of feedback and how this helps to understand customer needs and whether those needs are actually being met. Then, numerous approaches to asking for feedback were introduced, both direct and indirect. Finally, you learned about hypothesis-driven development and how a mindset of experimentation can help to cut down waste.

With this knowledge, you can now choose and implement feedback mechanisms that allow you to learn what the user sentiment regarding your application is. You are now able to implement an experiment-based approach to creating software, focusing on value-adding features and ignoring or even removing features that do not add value.

In the next chapter, you will learn all about containers. Containers are rapidly changing...

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

  1. True or false: There are no downsides to publicly sharing a roadmap.
  2. What is an important concern to keep in mind when evaluating user feedback on a public roadmap?
  3. What are two indirect indicators of user satisfaction that are relatively easy to capture?
  4. Which of the following is not part of a hypothesis, as used in hypothesis-driven development?
    1. A hypothesis
    2. A confirmation threshold
    3. A conclusion
  5. What are two benefits of interviews or focus groups over other means of gathering feedback?

Further reading

lock icon
The rest of the chapter is locked
You have been reading a chapter from
Implementing Azure DevOps Solutions
Published in: Jun 2020Publisher: PacktISBN-13: 9781789619690
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at ₹800/month. Cancel anytime

Authors (2)

author image
Henry Been

Henry Been has been working in IT for over ten years. He is an independent architect, developer, and trainer in a number of companies. With many of these companies, he has embarked on a journey implementing practices such as continuous integration and deployment, infrastructure as code, trunk-based development, and implementing feedback loops. Alongside his work, he creates online training courses for A Cloud Guru, and frequently speaks at meetups and conferences. He was awarded the Microsoft MVP award in 2019.
Read more about Henry Been

author image
Maik van der Gaag

Maik van der Gaag is an architect and trainer at 3fifty, an experienced consultancy company with a strong focus on the Microsoft cloud. He has over 15 years' experience of providing architecture, development, training, and design expertise. During his career, he has worked on a variety of projects, ranging from cloud transformations to DevOps implementations. He loves to share his knowledge, which was also one of the reasons why he founded the Dutch Cloud meetup. Maik is a public speaker, writes blogs, and organizes events.
Read more about Maik van der Gaag