I have worked with testers on an Agile team before and it has worked very well for both the team and the customer.  In my previous role at Bank of Ireland, testers who had come from a traditional testing background worked within our teams to help ensure we had quality deliverables at the end of each iteration.  It was different from traditional test approaches in that they were sitting with the team, collaborated constantly and were integral to the process of developing the solution.  I never found them critical of poor quality or guilty of ring fencing roles and responsibilities.  This was refreshing and without doubt a better way of ensuring quality than those I had experienced before.

Recently, here at Paddy Power, we have been interviewing for a number of open Agile tester positions.  I”m pretty sure I know what a good Agile tester looks like but I have often struggled to fully articulate what that entails.  I have had this book on my shelf for a couple of months and now I’m looking to it to help me fully understand what an Agile tester is. » Read more: Agile Testing: A Practical Guide for Testers and Agile Teams

The principle purpose of an Agile retrospective is to reflect on the recently completed Sprint in order to adapt the teams practices and improve the way in which they deliver software. Most teams will begin by asking three simple questions:

• What went well?
• What did not go so well?
• What changes can we make to improve?

Early on, I took this rather simplistic approach and to be quite honest very little insight was generated. There were still benefits in that the team were sharing their experiences and learning from one another but this became stale very quickly. I needed to learn more about facilitating Agile retrospectives and so invested in a copy of Agile Retrospectives by Esther Derby and Diana Larsen.

» Read more: Agile Retrospectives : Making Good Teams Great

Estimating and planning are inherently difficult and the mechanisms that Agile apply to these efforts differ significantly in approach and execution. In this book, Mike describes what makes planning so difficult and how an alternative approach can help alleviate the issues that arise with traditional approaches.

Again the quotes that Mike has scattered throughout the book capture the essence of the subject matter and so I have replicated them throughout this review.

» Read more: Agile Estimating and Planning

User stories are critical to the way in which an agile team discovers and delivers new features. They primarily act as place holders for features which form the product backlog. As the agile team begins a release or iteration, a planning exercise is performed in which user stories will be refined and estimates will be provided (with greater degrees of certainty as the process continues).

The utilisation of user stories by an agile team is significantly different to the way traditional teams utilise use cases or other types of requirement documentation. Through this book, Mike Cohn explains the what, when and how of user stories.

» Read more: User Stories Applied