I had a really great time yesterday at the Software Craftsmanship conference. Jason – thanks a lot for organising it and I am really looking forward to attending the conference next year as well. I was a bit surprised with the interest in my talk on Specification Workshops, especially as it was on a bonus track, added late into the programme. Thanks a lot to everyone attending, especially all those people that decided to stay and stand through the whole thing or sit on the floor once we ran out of chairs. Here are the slides and links that I mentioned in the talk:
- Slides (pdf)
- B2 Bomber crash (“all the systems were functioning normally”)
- Card, Conversation, Confirmation article by Ron Jeffries
- Crevasse of Doom talk at QCon 07 (printing in java)
- Exploring Requirements: Quality Before Design
by Donald Gause and Gerald Weinberg
- Sources of Power: How People Make Decisions
by Gary Klein
- Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
– my book with Specification Workshops as one of the central themes (also available as a PDF)
- Acceptance Testing portal with lots of additional resources and a video on the importance of realistic examples and acceptance testing
|
|
Thanks for your book. I’m looking forward to reading it, but currently I have to get through the other 10 books I already put on my shelf. I’ll keep you updating on our progress with the Specification Workshops. Last week I had an experience at work where your workshop could have helped before kicking off the implementation.
Enjoy it – I’d really like to hear your thoughts on it once it pops up to the top of that book stack.
Hello Gojko,
It’s great to hear that people found your example-writing (specification) workshop useful. A few days ago I listened to a talk by Rich Mironov (chief marketing officer at Enthiosys) titled “Product Managers and Product Owners: Which Do We Need, and What Do They Do?”. The main point of the talk was that product owners on agile teams can’t get a good outside perspective if they are present and participating in agile teams every day.
You address this on your teams by conducting specification workshops at the start of iterations and that participants from across all business functions including customers need to participate in this knowledge sharing and discussion. Many teams don’t think to address the issues well enough or discuss things enough to realize what they don’t know. I know in my testing, while I’ve always tried to solicit this sort of information from end stakeholders, finding them is always tough and getting useful information is even tougher. In the past, I’ve coped with this by exploring features as soon as they are implemented and discussing what I’ve learned with the product manager. This usually worked well, but often meant some rework by the developers to correct misunderstandings.
After hearing Rich Mironov’s talk, I realized that that we had a full-time product manager who was filling in as a part-time product owner on this project. He had good insights on end-customer needs, but we still had missteps when implementing the stories. Other times full-time product owners don’t have the “touch-time” they need with customers and prospective customers to understand what functionality might be really valuable. Rich suggested having a combination of product owners (one per agile development team) and at least one product manager who communicates between development, marketing/strategy, and the CEO (or whoever approves projects). He agreed that the POs and PM need to be in constant communication. I’m not sure whether he realized that acceptance tests could be used as a communication tool that’s able to reach to his level and beyond. I learned a bit more about the workings outside of development that are important to a project’s success. I learned more about how the PM can be a source for me to find more information about users with potentially different needs. I’m convinced that collaborative development of testcases by stakeholders across all these job functions can contribute not only to better upstream understanding of what to develop, but also better downstream understanding of what the software’s current capabilities are. Your book goes a long way in explaining that these are really communication issues rather than testcases. I’ve blogged a bit more on how Agile Testers should view this at:
http://agiletesterdotnet.wordpress.com
sincerely,
–
Bob Clancy