Hiccupps

The four presentations at CEWT #7 were on the topic of Dirty Testing Secrets. Here's my brief summary. According to Karo Stoltzenburg , we testers have a bad case of hubris about the uniqueness and value of our work. Not to put too fine a point on it, half of what we do is pointless and in any case could be done by someone else. Testers, she says, pride themselves on questioning, communicating and facilitating communication, and finding the important bugs but really they should find a bit of time to take a long, hard look at themselves. Questions? She's heard better from developers, subject matter experts, product owners. Testers have no monopoly on critical thinking and people in other roles have information and experience to bring to the table that testers often won't. Communication? Sure, it's common for testers to bring people together but we're also often then an extra node in the information flow network, a contributor to the cacophony of Chinese whisp...

After the presentations and discussions at  CEWT #7  we split into groups for a Lean Coffee session to pick up threads from the day. Here's the topics and aggregated comments from the group that I was in. I would love to see Devs discuss their purpose like this/Why does testing give itself such a hard time about value? Thinking about this stuff allows people to focus their time in the areas they want to work in. It helps managers know what motivates their staff. The purpose of a developer is to solve problems for people. Testing is never voted highly enough to get discussed at developer Lean Coffees I've attended. Testing is evolving because the context in which we work is evolving, so we need to reflect on our role constantly. Self-reflection is a strong testing skill ... we expect thoughtful analysis of other things by testers, so why not also of themselves? This group (at CEWT) is self-selecting and not representative of testers in general. Do we really feel...

The topic at CEWT #7  last weekend was Dirty Testing Secrets. I decided to present something reasonably provocative as a conversation starter. I think it worked. The essay below is a pretty version of the notes I prepared in advance. --00-- Quality Assurance. QA. It's getting less common, but it's still not unusual for people in software to talk about getting something into QA or to asking us to QA their stuff. I've worked hard over the years at our place to spread the word that I don't think of my team in that way. I do an induction for all new employees and explain how testing is a creative and intellectual activity, not a checkbox ticking drudge. Sadly, I still encounter career testers who think that their role is to confirm that requirements are met and no more. But my sense is that that's an open secret rather than a dirty one. This isn't a dirty secret either, although it might be a surprise to some: That's not to say that we ar...

At CEWT #7 today I surprised the participants by asking them for some definitions as they arrived. I used the definitions in my talk, which I've blogged about , but for now here's a simple list. Add your own definitions in the comments if you like. Quality How well someone perceives something works and meets a set of requirements. Value to someone who matters at some time. Quality is value to some person that matters. You'll know it when you see it - when something is good, shiny, runs smoothly. External quality is a positive characteristic of software encompassing robustness, correctness, and lack of bugs. An outcome that satisfies all stakeholders + customers. The extent to which any given attribute of a "thing" meets its intended or desired purpose. A positive attribute of something (as in "a quality of ..") Quality is subjective and hence hard to define as what's quality for some is not for others. Initially I was going to say wh...

For my lightning talk at Cambridge Agile Exchange last night I tried to persuade the audience that, even in today's agile world of self-organising teams and coaches, value can still be found in the traditional management literature. I talked about three books which unashamedly acknowledge that everything revolves around people: Managing Humans by Michael Lopp Behind Closed Doors by Johanna Rothman and Esther Derby Managing Yourself and Others by Gerald M. Weinberg That's right. Everything. People. Literally. Everything. Is. People. In ten minutes I couldn't do more than pull out a handful of key messages and these are the ones I chose: Do be congruent. Do be open. Don't be a prick. They seemed to like it. Particularly the last one. Here's the slides: I also wrote notes on the other talks . Image: Cambridge Agile Exchange

I gave one of six lightning talks at Cambridge Agile Exchange last night. Here's a quick summary of the others and, up top, my sketchnotes. Brian Beckett spoke about three major problems of engineering management: goal-setting for individuals, metrics for teams, and people . People are worst, he said, but also people are the best, and in fact are the only thing. For Brian, software development is an art and its practitioners will artfully game quantification, so engineering managers must be art critics, and favour qualitative assessments. Dani Oliver described how following his passion for agile approaches has led him from development through Scrum Mastery and into a role as a Release Train Engineer in the SAFe framework. And what is an RTE? He gave us his take on it: the keeper of (weird) practices, a breaker of the status quo, an uber Scrum Master, someone who cares. Mariapaola Sorrentino described joining a Scrum team where commitment was low relative to delivery (in ...

I started writing Hiccupps just about eight years ago so, following tradition, here's an anniversary selection of pieces that I am particularly pleased with from this year: The Value of Testing is ... Don't be a Prick The Value in Values Amazingly, at 424 posts, I've managed to average one a week over the long haul and I don't think there's been a month in that time where I haven't published at least once. I spent a little time reflecting on that, wondering what my motivations are these days. I think they include: a desire to be alert to my thoughts and feelings, and to shine a light onto what they are, and where they have come from, and how they compare to other people's and my own at other times. a desire to document my learning as I branch into new areas such as management, or sketchnotes, or idea generation. a desire to record the ideas of others and the thoughts they've sparked in me. I use writing, only some of it on this public bl...

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 busines...

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