Hiccupps

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

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

At CAST 2022 Amber Vanderburg told us that when you want to make a change, particularly something innovative, start with the Why. Why? So that everyone involved can understand the motivation and direction of travel. I've learned that myself over the years too, from Simon Sinek , and it has the added benefit that conversations about the merits of the Why can be had before any implementation starts. Of course, being honest about what the Why is is important too, if you care to maintain trust over time. Amber suggested a few things that help to navigate the change once it's underway. The How of the Why, if you like: proactive conversation: some kind of formal structure, some way for all voices to be heard, perhaps with a time box to stop things dragging on. awareness of fundamental attribution error: where someone's apparent motive (e.g. antagonism) may not be their actual motive (e.g. sharing potential alternatives). strength and weakness alignment: being clear with one ano...

I joined a new project this week. Me and a couple of engineers from my team are being asked to build a service to provide access to data sources, both in-house and external. As the lack of this data is being felt some distance from our team's main product, we haven't been involved in conversations up to this point. A kick-off meeting was the first opportunity for us to meet the various stakeholders and hear them say in their own words what they're looking for. This is usually an interesting phase in a project because there's lots of scope for ambiguity, conflicting vision, missing requirements and so on. But how to navigate it? No two projects are the same so I don't have a standard approach. The things I did around the meeting are reasonably typical and include: I looked for project documentation on Confluence, read it, and tagged the pages. I looked for other Confluence pages on the same topics, and tagged them too. I looked in Jira for recent tickets on the same ...

  We asked one hundred customers how they'd like teams to approach work on their projects. It's long been my intuition that the families on Family Fortunes will almost always choose to play, overtaken by the adrenalin buzz of starting something, unhindered by any consideration of the context or subject matter.  The view is supported (thank you, Internet!) by Nicholas Boy's informal analysis Pass or Play: A Data Driven Approach to Family Feud . Out of the one hundred face offs I watched, can you guess how many times the teams passed? Nope, less. No, seriously, less. Twice. The analogy is weak I know, and I doubt it's as high as 98% at work, but I've seen so much started with so little consideration of anything other than some potential positive wished-for outcome.  Every time, I imagine the line of Sunday Best grandparents, trying-to-be trendy nephews, and that weird extrovert brother-in-law, all waving their hands in the air and shouting ... "PLAY!" Imag...

  Rob Sabourin's Becoming a Code Listener session at Worqference has just finished. Although the presentation ostensibly covered technical practices, a recurring theme was how important collaboration is to establish shared understanding, intent, and context. During the Q&A, in response to a question about introducing code listening activities on a team where collaboration levels are low and testers have no access to source code, Rob dropped a beautiful analogy. As a student he used to go to high school dances. What he found was all the boys along one wall and all the girls along another. Not dancing. As a consultant he goes to client planning meetings. What he finds is testers sitting in the corner, silently, angry about the meetings being a waste of time. Not collaborating. Testers, if we want more satisfying interactions, if we want others to collaborate with us, if we want to show that we have something to offer, we have to step up and actively participate. It may feel revo...

Elisabeth Hendrickson was on The Confident Commit podcast recently talking about systems and flow, and her new Curious Duck project. Towards the end she was asked a question about individuals, teams, and judging success. Her answer was simply super: The team has to be the agent of work. There are many reasons for this but it's a key tenet for me in leading any organisation. If the team is the agent of work then what that means is the individuals absolutely contribute to it and deserve to have growth paths and career paths and be rewarded for their contributions, etc. So individuals matter very much. However if somebody decides to go on a four-week vacation to Bali, work cannot stop on the whatever-it-was, they can't be the single point of failure. So if you have the team as the agent of work, the team can swarm on things, the team can have a set of working agreements internally for how they're going to accomplish things. There's plenty of space for the individual but...

I watched Allan Kelly 's Reawakening Agile with OKRs presentation at the Cambridge Agile Exchange last night. You can find a lengthy summary in his recent article for InfoQ and there's a book too, but here's a few points that caught my attention. If you've been around the block you'll have doubtless come across OKRs — objectives and key results — and perhaps cynically think of them as the antithesis of agile working, a management tool for the top-down imposition of overcommitments. From that perspective, promoting OKRs as a way to save agile could look a bit like the kind of sharp tactics that unscrupulous second-hand car salesmen might employ: "OKRs, one careful owner, a nice little runner, thousands of miles left in this one." Fortunately, Allan is open about the history and specific about the contexts in which he thinks OKRs can add something. In his view, their backstory is why OKRs are also a useful hack for the kind of "mil...

A developer I don't work with often made a change, tested it against the problem case that motivated it, and then asked me to have a look. I started by reading his description of the testing he'd done, reviewed his commits, and then ran the application with and without the change. After testing for a short while I went back to him having found a major problem. This isn't a blog post slagging off how developers (don't) test, it's also not about how testers should strive to create a quality culture and coach the team, and it's not about how clever I was at finding the problem either. This blog post is about the response the developer gave when he heard my report: "what made you think to test it that way?" Which is a great question from someone who wants to improve themselves and their work. I didn't want to put him off ever asking me anything ever again by taking the opportunity of an apparently receptive audience to lard on the test...