Whilst travelling back on the train from UKTMF in January I happened to sit opposite another of the conference attendees on the train Steve. We got chatting and I found that Steve ran the BA and testing for insurance company Unum, where we realized we had a common acquaintance. A tester who had worked in a team I ran in a previous role now worked for Steve's department. As we talked about our common acquaintance and our own jobs it soon became apparent that, although we both ran testing operations, the cultures and approaches in our relative teams were significantly different. I described to Steve how we operated in an agile environment with high levels of collaboration and discussion and an exploratory approach to testing backed with high levels of automation. Steve's environment, on the other hand, was one of a classic staged approach with extensive documentation at each stage and heavy use of scripted manual testing. As we talked an idea started to form of doing an 'exchange' scheme, with members of our teams visiting the other to examine their processes and learn more about their relative cultures.
An Exchange Visit
A few weeks later one of my team spent the day in Unum's Bristol offices. She spent time with testers and managers in the company learning about their approach to testing and the processes and documentation supporting this. She returned from the day with a wealth of information and a hefty set of sample documentation. Our whole department attended a session where she presented her findings from the day. As Steve had described she explained that the process was very formal, with a strong reliance on scripted manual testing in HP Quality Centre. What was also clear was that Steve's team took quality seriously and were achieving very high levels of customer satisfaction with their approach. Legislation was a key driver in requirements resulting in long predictable feature timescales. The fact that their feature roadmap was fixed months in advanced allowed a more rigid documented approach to be successful. The long turnaround times on new features were both accepted and expected by the business.
The return trip
One week later we received a visit from one of the senior testers from Unum, Martin. He'd was a very experienced tester within the organisation, having moved to testing from a role in the business 15 years earlier (Steve later explained that around 4 in 5 testers they recruit are hired internally from the business). I spent the morning with Martin discussing our approach to testing and explaining our use of: -
- continuous integration
- automated acceptance testing
- collaborative specification with examples
- thread based exploratory testing
Before one of my team took him through some examples of our exploratory testing charters.
Martin was really interested in our approach and I think the success we were achieving with very lightweight documentation was a real eye opener. He appreciated the fact that our approach really gave us flexibility to pursue new features and change our priorities quickly, allowing us to be competitive in fast moving markets.
We discussed whether a more lightweight agile approach might be suitable for some of Unum's projects. Our visitor's gut feeling was that they would struggle with larger projects due to the lack of management control through the documentation and surrounding metrics, and would most likely have to trial it on some smaller developments. Bugs for them, for example, were an important measurement of both tester and developer efficiency. The fact that our team often didn't raise bugs , preferring a brief discussion and demo, was not something that would have fitted well. I can understand this, however a potential pitfall on taking this approach is that the small scale projects would be likely to be short term with limited scope, yet the biggest asset of an agile approach is delivered through an ongoing process of continuous improvement. The greatest benefits that I've seen through agile have been as a result of a maintained commitment to the principles of collaboration, team autonomy and usually testing automation that underpin it. Doing short term 'trials' of an agile approach would be selling the ethos short. Martin and Steve both understood this, and felt that it would hinder their adoption of agile methods.
This week Steve was kind enough to visit our office to review the exchange and discuss any future steps. I plan to visit another of Unum's offices later this year to learn about their performance testing, and Steve has suggested to his development team that they consider sending one of their number to visit our team as well.
It may seem counter-intuitive that two teams with such different cultures would benefit from such an exchange, however I have found it really useful. I can understand why the differences exist between our relative organisations, and there is still a huge amount that we can learn from each other. Theirs is an older company with proven success with a mature methodology. Given their historical success they are naturally wary of new methods but doing an exchange like this shows that Steve and his team are have an open mind about different approaches and a pragmatic view on their ability to adopt them.
The biggest lesson that I have taken away from the exchange was that, whatever methodology people are working with, great teams can and will deliver great software. Having worked on testing proects in more traditional methodologies before, this was more of a timely reminder to me than a new idea. Having now worked in a successful agile environment I know that my preference will now always be for an leaner more iterative approach. Steve's department may be doing things 'old school' but they are doing it in a positive and professional way, which means there is a lower incentive to change. I would rather work for a department like Steve's than an organisation who has adopted agile methods as a knee-jerk reaction to failures due to bad management and cultural shortcomings.
image : http://www.flickr.com/photos/xtianyves/7110002847