Chapter 18. Concluding thoughts

 

I began my research for this book because I was seeking external confirmation. I wanted to document that there are many teams that produce great software using agile techniques. I hoped that they were using BDD, agile acceptance testing, or what I would come to call Specification by Example. I thought I already knew how these processes worked and that I would find other people applying them in the same way I was. But the more research I did, the more unexpected lessons I learned. I found that many teams working in different contexts used a variety of practices and techniques to get to the same results. This proved that there’s no such thing as a “best practice.” Software development is incredibly contextual, and what might seem like a good idea for one team might be completely wrong for another.

Looking back, it surprises me how much I’ve learned about delivering high-quality software effectively. Some of these discoveries were completely new to me. Some were the result of viewing something with which I was familiar from a wider perspective, which gave me a much deeper understanding of the real forces behind the practices. To conclude this book, I’d like to present the top five things I’ve learned.

Collaboration on requirements builds trust between stakeholders a- and delivery team members

Collaboration requires preparation

There are many different ways to collaborate

Looking at the end goal as business process documentation is a useful model

Long-term value comes from living documentation