Hiccupps

We don't have any business analysts at our place but I'm interested in the role and the potential insights a BA can bring to software development. Historically, I've wanted my testing to be concerned with more than whether the desired scope was implemented: I want it to wonder whether that scope is targeting the right problem and, if it is, whether some other scopes could solve it too, and what the relative merits of each are. I think this kind of work overlaps with the things a BA might do, but perhaps with sharper tools, and I perceive that there's crossover in the skill set too. To give my thoughts some more grounding I looked for an intro book and chose Business Analysis Agility by James Robertson and Suzanne Robertson. Why that one? Because it talks end-to-end about software development in contemporary environments, because it's got worked examples, and because I liked what Johanna Rothman's five-star review on Amazon said about it: This book bu...

  We play tricks on ourselves, Woody Zuill says. We think that we estimate because it gives us control. In reality, we estimate because we fear losing control. The irony, of course, is that we aren't in control : estimates are inaccurate, decisions are still based on them, commitments are also based on them, projects overrun, commitments are broken, costs spiral, ... Spending more time estimating typically doesn't make us better at estimating but it does take time away from doing.  Zuill's experience is that it's possible to build software without any estimates by taking an important piece of functionality, building only the absolutely critical pieces of it, and then putting it in front of someone. The doing, and the review of what's been done, will help to determine what should be done next. Sounds simple? Yes, but it's not easy . It's crucial to find allies and customers who are ready to accept it. Here's my tidied-up sketch...

I was at Cambridge Agile Exchange 's first Unconference the other night and I pitched a 15-minute discussion with the title  The value of testing is ... : I'm a tester and I'm interested in the value that others perceive testing brings to product development in their contexts. Where does testing add value? Where does it add most value? When does it add value? What kinds of testing activities deliver the right kind of value at the right kinds of costs? Do you need testers in order to test?  The participants in the session included product owners, scrum masters, developers, coaches, an ex-test manager, and a colleague from Linguamatics who has just switched to testing from linguistics. (And I'm still hiring .) The mission I had in mind was to gather data, to solicit and record views, and to not push some kind of militant testing agenda. I think that worked well, and if I had to pull one observation out it'd be how quickly the conversation turned to  th...

Yesterday's Team Eating (the Linguamatics brown bag lunch thing I organise) was called A Linguist's Idioticon . In it, one of my colleagues gave an overview of some of the linguistic terminology used in the natural language processing components of our core product, I2E. In a section on wh-words, Rudyard Kiping's  Six Honest Serving Men  were listed: I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who. Aside from any interesting language properties they might have, you might have seen these words presented as perspectives from which to view a situation  alongside techniques like Edward de Bono's Six Thinking Hats . In passing, the presentation noted that which and whose are rarely included when people are asked to list wh-words (and, as a further aside, and the talk had many of those, neither are whom  or whither — but they are pretty archaic these days). It occurred to me tha...