You sometimes get a superficial answer in a retrospective and to understand what has happened need to dig deeper to find the underlying cause. The system thinking archetype "Shifting the Burden" shows we may treat symptoms rather than the disease leaving the underlying problem to grow.
To drill down to cause rather than effect, a technique I recommend is "Five Whys" drawn from Taiichi Ohno's Toyota Production System. See also Peter Senge's "Fifth Discipline".
All you need to do is simply ask the question "Why?" five times over. Note that observations based on actual data rather than pure logical deduction is the best way to answer a "Why?" question.
Interesting that questions starting with "Why" are not deemed powerful questions by some. I would like to understand the anatomy of questions better but ..
"The important thing is to never stop questioning" (Albert Einstein)
Registration is now open for the upcoming XP 2004
Here are some of the highlights in the program:
- Mary Lynn Manns and Linda Rising on:
Leading Fearless Change -- Introducing Agile Approaches and Other New Ideas Into Your Organization
Michael Hill on:
Transitioning to Extreme Programming
- Monika Bobzien and Wolfgang Stark on:
It donīt mean a thing, if you ain't got that swing: Balancing Learning Processes in Organizations
- and of course more talks, tutorials, activities, papers, panels,
posters, and workshops!
See you in Garmisch-Partenkirchen, Germany!
I presented a tutorial at OT2004 conference entitled "Getting Your Story Straight". Credit should go to Richard Watt (ThoughtWorks) for the title, a technique that he has written about with Dave Leigh-Fellows in their paper on Acceptance Test Driven Planning. In this session I was not specifically talking about his technique but the general difference between Use Cases and XP Stories.
To sum up when you write use cases you are expanding requirements but detached from cost of doing this. When you are writing stories you are concerned with planning iterative development and bear the cost of development in mind. Although stories can be identifed by an on-site customer developers hold essential information about how the system may be developed in increments and can help the customer slice their stories smaller. QA's can help the customer write better acceptance tests.
James Robertson's blog has a write up of the OT session.
He kindly does not mention that the session was a little chaotic at times!