Hiccupps

The latest episode of the Vernon Richard Show, New QA Job? How We'd Decide Where To Start , answers this question from a listener, Shady: When joining a new organisation, how do you decide which QA domino piece to tackle first for the rest to easily fall into place? For example, you might find flaky test automation, poor testability in user stories, no integration tests, limited test management tools, missing test data, and an ever growing regression suite. With so many improvement opportunities, how do you prioritise what to fix first? As usual the conversation ranged freely and I've picked out some of the key points with a little commentary here: It Depends : usually the right answer or, rather, a small part of the right answer. The rest should be what it depends on and how that affects your answer. Investigate the Context First : exploring to understand the context is a reasonable default in a new job. You'll want to understand the key ...

You've almost certainly heard of the Prisoner's Dilemma : two members of a crimimal gang are captured and interrogated separately. The police tell them both they are looking at a year in prison but offer a deal if they squeal: less time for incriminating their colleague. There are three scenarios: No-one talks: the default one year each One talks: the talker goes free , the other gets three years Both talk: both get two years  The dilemma is whether to remain shtum and trust the other will do the same  or  to spill the beans with the risk of an extended stay in prison but the potential reward of walking away scot free.  Given that they are sure the other would be prepared to rat them out, the rational individual's strategy, according to game theory, is to talk even though there is a better group outcome in not talking. --00--   The Prisoner's Dilemma is merely a well-known example but there are many other games with different setups and constraints. I came acros...

  Hands up if you think the world needs another format for retrospectives.  Yeah, right.  Yet here I am. Last October it was clear that we were becoming jaded. After a phase of novelty themes (at the festival, NSYNC, 8-bit video games, ...) and a long stretch of Stop Start Continue , engagement in our retros was sliding. So when it was my turn to facilitate I wanted to find a different format and I had some specific requirements in mind: a simple and intuitive structure, invitations to express feelings, and opportunities to be publicly grateful.  I didn't find an existing template that fit the bill so I made one up, just four columns in a basic table with these headers: Kudos to ... 'cos of ... I like it when ... I feel meh about ... I don't like it when ...   I expected it to be a one-off palate cleanser but it's proven popular and we've been using it for six months straight.  There's no originality in those categories, by the way: I see a strong fami...

I was guest speaker for a software testing class at EC Utbildning  a couple of weeks ago. I talked about one of my hobby horses — using automation to amplify my ability to explore — and I'll give the same talk at the Ministry of Testing Cambridge next Tuesday. Perhaps you can make it? Chatting with the Swedish students on the call before my presentation I asked what they liked about testing and, as no-one seemed to want to go first, I gave my own answer: I enjoy testing because it mixes technical, social, and intellectual challenges. And that's true but it isn't always enjoyable in the moment . Last week at work, in a small group session, I offered to share my screen while we tried to exercise and then, when it wasn't working, debug some new monitoring functionality. Honeycomb is a valuable tool, and I've used it plenty of times, but not at an expert level. The instrumentation we'd been developing is based on existing...

  Over on the Agile in the Ether  Slack instance one of the Ethernets recently asked: MoSCoW: Does anybody have a simple way of explaining when items should be Must vs. when they should be Won't? Is it really as simple as whether it's an inclusion or an exclusion of the item? MoSCoW  is a basic approach to grouping project work into buckets graded by priority: M: must have S: should have C: could have W: won’t have (for now) I'm sure every one of us has been in conversations where the buckets are filled and then stakeholders say they're all emergency-level important, but that's not today's problem. In this case the questioner had been burned by people twisting the words in unhelpful ways: " must not do ..." (i.e. won't) or " won't  do without ..." (i.e. must) which only makes the often fraught prioritisation discussions even less pleasant.  I have found MoSCoW to be useful so I shared an exa...

The theme at  LLEWT this year was Rules and constraints to ensure better quality.   My experience report concerned a team I'd been on for several years which developed (bottom-up) a set of working practices that we called team agreements.   The agreements survived "natural" variation such as people leaving and joining and even some structural reorganisation which preserved most of the team members but changed the team's responsibilities or merged in a few people from a disbanded team. The agreements did not, however, persist through a significant round of (top-down) redundancies where the team was merged with two others.  I'm interested in thinking about the ways in which constraints on how people work affect the work and whether there are patterns that could help us to apply the right kinds of constraints at times they are likely to be useful.  I'm going to use this post to dump my thoughts. My starting po...

It was my wedding anniversary recently. The picture at the top is the front of the card I got for my wife. Yeah, I know. Somehow she still loves me. I asked my family which bean out of the couple they thought I was and everyone chose the one on the left, including me. Surprised, I showed the picture to my work colleagues and they also unanimously went for the left-hand bean. Why? Here's some of the reasons I was given: the legs it's spilling its drink, like a man would the light reflecting off the top of the head  the man always stands on the left in wedding pictures  it looks like you I don't want to go deep into this, especially that last point, so I'll just observe that despite strong surface agreement there was significant hidden misalignment in motivation. Like so many projects I've bean on. 

Whatever our workplace constraints, we have agency over our own actions and the choices we make impact us, those around us, and the work we do together. We'd prefer to make good choices, naturally, but good for who, when, why? In a short talk that I gave to one of my teams this week, I pulled out nine heuristics for working that have served me well over the years. Heuristics are rules of thumb: things that generally give the right kinds of result but are fallible, a good default but not a guarantee.   The talk covered three core areas: being clear to yourself and others navigating relationships doing the work effectively and here's the slides: You'll notice that there are no credits in the slides themselves. Instead I linked to blog posts where I've pointed to the sources and commented on the interpretation I've taken, or the use I've made, or the value I've extracted. That's important, because these ar...

    A long stretch of a major route into Cambridge is being widened at the moment. To facilitate the work, one of the road junctions near my house was out of action for a long time and only reopened the other day. I didn't quite do a Laurel and Hardy comedy double-take as I walked past it for the first time, but I certainly took a second look. And a photo. Why? Because the triangle is painted the wrong way round and is, I think now that I've skimmed the regulations , too close to the double-dashed lines across the road as well.  In fact, it seems that the triangle may not even be required but, if it is used, it should look like the left-hand side here: Of course, we all occasionally mess up the simple job that we've done a million times before because we're on autopilot, or rushing, or doing something else at the same time. Understandable, but embarrassing and difficult to unsee or live down, particularly if there is a significant unwanted side-effect, such as a car cra...

    This week at work my team attended a Myers Briggs Type Indicator workshop. Beforehand we each completed a questionnaire which assigned us a personality type based on our position on five behavioural preference axes. For what it's worth, this time I was labelled INFJ-A and roughly at the mid-point on every axis.  I am sceptical about the value of such labels . In my less charitable moments, I imagine that the MBTI exercise gives us each a box and, later when work shows up, we try to force the work into the box regardless of any compatiblity in size and shape. On the other hand, I am not sceptical about the value of having conversations with those I work with about how we each like to work or, if you prefer it, what shape our boxes are, how much they flex, and how eager we are to chop problems up so that they fit into our boxes. Wondering how to stretch the workshop's conversational value into something ongoing I decided to write a README for ...

A couple of weeks ago I was asked to facilitate a group risk analysis for a project. The session would be remote and, having participated in this kind of thing before there were some things I knew I wanted to avoid: unclear mission participant overwhelm and underwhelm intangible outcome The tools I had to work with were Miro and Google Meet. Unclear Mission I wanted to minimise time on the call where we were not looking at risk so I decided to prepare a concise intro to the project, the mission for this session, and our approach to the analysis. I was the facilitator rather than a participant and it's not my project so I didn't need deep knowledge but in order to scope the mission I wanted some background.  I briefly reviewed the project documentation, got a picture of its status from a couple of people, and proposed to the PO that we review only a slice of it.  That slice was one I thought we could plausibly fit into a two-hour session, that would have value to the project ri...

  Episode 20 of Oddly Influenced , Brian Marick's podcast, is concerned with Julian Orr's book, Talking About Machines .  Orr makes much of war stories , the tales that colleagues tell each other about work they've done to help solve a live problem, commiserate about something that's gone wrong, or build culture. I recognise this from the teams I've been part of, communities of practice I've participated in, and meetups and conferences I've attended and run. Those stories establish our credentials, and to an extent our status, in our peer groups. Almost as an aside, the podcast mentions another kind of story, this one aimed not at the peer group but at those who are asked to assess their performance.  The group of technicians followed by Orr in his book were evaluated in part by account managers at the companies they were assigned to; people usually very distant from the technical work. This lead the technicians to go out of their way to make the outcomes of...

  I saw Maaret's Pyhäjärvi's post on LinkedIn   the other day. This line chimed strongly with me: Sense of lack of time. Someone asked how to have joy of discovery when feeling always pinched with time. We have in many cases lost control over time, and I have done work I have not necessarily appreciated on making time flexible - always seeing there is a next day and having no schedules and small slices of work. I feel like I do my work at various granularities across multiple dimensions and so, to begin to get this idea straight in my head, I tried to list some of them. It was harder than I thought it would be because so much of this is instinctive, intuitive, and in the moment. Given that, here goes draft 0.1. Hopefully I'll begin to feel more familiar with the idea and be able to revise the model later on. Scope Parcel of work . My team's practices are reasonably common, I think. Tasks are portioned into into Jira tickets which progress out of a back...