Hiccupps

I recently flew from London to Austin, Texas and back. It's a tedious flight in both directions and despite my thick book, my lengthy podcast playlist, and a Kama Sutra of attempted sleeping positions, there were still times when I found myself at a loose end and decided to fiddle with the in-flight entertainment system. Here's a few of the fun things I found, where the pictures came out bearably ... Zooming in as far as possible to the destination, it appears the plane's trajectory ends before the airport. (Gulp!) There is some disagreement about how far it is to the destination (59km, 61km?) and, by zooming and rotating the view appropriately, Austin and Austin Airport (with the star) are apparently located adjacent to one another while somehow Austin also looks to be closer to the plane (just along the yellow path off screen to the right) and simultaneously further away (63km). On the way home now, and we've reached the end of the flight somewhere wes...

Pete Douglass and Karl Chambers are Scrum Masters and recently found themselves dissatisfied by projects that they'd worked hard on but were (a) taking a long time to get anywhere close to deployment, (b) being delayed by late-breaking feature requests, (c) both of the first two, and (d) not fazing the business at all. As they saw it, the business likes to see its people getting on and doing stuff. If using Scrum, the business typically likes to see a consistent or upward-trending velocity for its teams: more work being done. The business will often not differentiate between between a simple proxy metric and the thing they'd really like to measure, between work done and value delivered, between outputs and outcomes . In their talk at  last night's Cambridge Agile Exchange  Pete and Karl described a couple of ways they tried to help the business side to see that having busy development staff wasn't the same, or even directly related to, the delivery of business v...

X: What's your dream job title? Me: Sympathetic Sceptic. X: ? Me: I want to help people to get to the best thing they can, given their constraints, for their definition of best, at this time. X: ... Me: I want to help them by probing the idea of the thing, and the motivation for it, and the way it is made, and any other relevant and important factors to them right now .  X: ...  Me: And I want to offer to propose potential factors too, for as long as they feel it's helpful . X: ... Me: And I want to suggest alternative perspectives, with varying degrees of viability, to compare their thing to, until they are happy enough with a version of their thing for their current purpose and costs . X: ... Me: And I want to do that with humility, remembering that it's their thing not mine , and they can do whatever they want with whatever I have to say. X: ... Me: Not that I've given it a lot of thought, you understand. Image: https://flic.kr/p/krEfv

When I asked Twitter this: Anyone know of a course on risk analysis that could work as in-house training for software testers?   It's a topic we're interested in but the stuff I'm turning up is more to do with corporate analysis, register building , mitigation at the business level #testing #risk Paul Hankin  suggested a book, Superforecasting, The Art of Science and Prediction , by Philip Tetlock and Dan Gardner. As the title suggests the book is about prognosis rather than peril, but the needs of prediction and risk analysis overlap in interesting ways: understanding possible outcomes, identifying factors that contribute to those outcomes, and weighting the factors and their interactions. Tetlock and Gardner study forecasting and forecasters. They use a metric called the Brier score to assess the accuracy of forecasts, and, over time, and with repeated forecasts, it becomes clear that some people tend to make better forecasts than others. The Brier score...