Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
The Agile Developer's Handbook

You're reading from   The Agile Developer's Handbook Get more value from your software development: get the best out of the Agile methodology

Arrow left icon
Product type Paperback
Published in Feb 2018
Publisher Packt
ISBN-13 9781787280205
Length 398 pages
Edition 1st Edition
Concepts
Arrow right icon
Author (1):
Arrow left icon
Paul Flewelling Paul Flewelling
Author Profile Icon Paul Flewelling
Paul Flewelling
Arrow right icon
View More author details
Toc

Table of Contents (16) Chapters Close

Preface 1. The Software Industry and the Agile Manifesto 2. Agile Software Delivery Methods and How They Fit the Manifesto FREE CHAPTER 3. Introducing Scrum to your Software Team 4. Gathering Agile User Requirements 5. Bootstrap Teams with Liftoffs 6. Metrics that will Help your Software Team Deliver 7. Software Technical Practices are the Foundation of Incremental Software Delivery 8. Tightening Feedback Loops in the Software Development Life Cycle 9. Seeking Value – How to Deliver Better Software Sooner 10. Using Product Roadmaps to Guide Software Delivery 11. Improving Our Team Dynamics to Increase Our Agility 12. Baking Quality into Our Software Delivery 13. The Ultimate Software Team Member 14. Moving Beyond Isolated Agile Teams 15. Other Books You May Enjoy

No more bugs

Back in Chapter 8, Tightening Feedback Loops in the Software Development Life Cycle, we discussed how we tighten feedback loops from a variety of sources for us to ascertain two things:

  • Are we building the right thing?
  • Are we building the thing right?

Bug reports are a form of feedback that we should welcome, as they are the most straightforward problem detection system we could ask for. They cover many facets of our software, from a user requirement not being quite right to a broken API connection, from the user experience not being satisfactory to performance being suboptimal.

Some teams try to argue that a bug isn't, in fact, a bug. For example, they may say it's a case of the business requirement being wrong. Perhaps the user didn't know what they wanted. This is old-school contract thinking, which gets litigious because of the upfront promises...

lock icon The rest of the chapter is locked
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.
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 $19.99/month. Cancel anytime
Banner background image