Transcript
I'd like you to consider this picture for a moment. Think about a time when a colleague made you do this by something they've done, or maybe something a previous colleague had done in their code that you encounter years later. I'm sorry to make you suffer, but consider that for a moment. Then having thought about that, if you'd like to share it with us, consider this a bit of group therapy if you like. If you'd like to share one, please raise your hand. Come on, somebody has suffered. There you go, there’s one.
Participant 1: There's been a couple of cases of I wouldn't say critical bugs, but looking at bad patterns of stuff that's three or four years old. And then you open up, get blamed or something and then you realize you're the one who actually wrote the code.
Ollis: Oh, yes. Sometimes the idiot is you, right?
Participant 1: Yes. And that's a humbling experience.
Ollis: Anybody else? One here. There's one in the front, Sangeeta.
Participant 2: Working for an English company and my French colleague wrote his code in French.
Ollis: You said that we had one more at the back there?
Participant 3: I once drafted a very angry email about 1,600-line method that I found in our code base and then reserved myself and said, "No, that's okay." And I clicked on the method it called and it was 2,200 lines.
Ollis: Oh, my goodness. And how many parameters, just out of curiosity?
Participant 3: I did not bother to remember that number.
Ollis: The most I've heard was about, I can guess it's 231 parameters, somebody told me about. Okay, so I feel your pain. Thank you very much for sharing those and I hope you have nothing else that gives you a bit of a therapeutic experience. But yes, I've been through this too. This "why did they do that moment?" There is another phrase for this, as Sangeeta suggested this morning. This is why there's a site called The Daily WTF.
I was a programmer myself for a very long time. Not far enough back that I ever used punch cards myself, although my sister was actually a punch card operator when I was little. So all of our shopping lists were written on broken punch cards, basically. Certainly, not old enough to use punch cards like this, but I wanted to include this one because I had a punch card in there anyway. This is from the Musée Mécanique, the vintage arcade game place down at Fisherman's Wharf, which has got some beautiful player pianos and all kinds of end of pier amusements right through from Victorian times through to 1980s arcade games. Great fun.
Speaking of which, they have Pong down there. Now, this is my vintage. This is was my first ever video game. I had this for Christmas one year. And I had to show this even though it's a rubbish picture with my reflection in the screen and everything. Because I managed to completely trance a boy of about 12 playing a video game, 11-3, because he had just no idea. If I was playing him on his console, I would stand no chance. But this one was my game, 11-3 victory.
In the course of that career, obviously, if I date back this far, I've had quite a few occasions as well of, “Why did they do that?” So that's what has brought me to being here because I got more and more interested in what's going on here? What's happening with the way we approach software development? And less and less not interested in being told to quickly add something to an existing code base that's held together with chewing gum and string, and being told to do it as fast as possible. Normally, not being able to put the craftsmanship into it I would like to, but really interested in how people approached what they could do with the time they had.
I gave up a perfectly well-paid career as a software developer, went and studied for a Bachelor's degree in Psychology. Still interested in what the hell's going on in people's minds and started a PhD. And now almost finished that. Just one tiny matter of reviver to get through next January. Once I've done that, hopefully I will be Dr. Ollis. Then what I've been researching is based on my own experience as a developer, having seen what it's like to be a developer, but also applying my psychological skills to that to try and figure out what the issues are, where is that and where does that from? And how can we use that to make things better?
Obviously, for PhD, what I think “that” is, the things that have annoyed me, there was one guy who had a state machine hammer and everything looked like a state machine nail to him. I said, “Neil, why have you done this as a state machine?" That was on my “that”. He was also a great fan of copy and paste. Oh, my goodness, he was a fan copy and paste. But that's not a good enough view. Me being pissed off with some things that other programmers is not a firm basis for a PhD.
I'll be telling you about research in three stages. First off, I did interviews with a lot of experience programmers, the likes of people who come to QCon. A lot of people who between them they had over 400 years of experience, to ask them what affects them? What are the things that give them difficulties? Because if they are novices, people who are novices, they don’t have problems because they are novices and it's hard to separate that out from things that are actually practices that affect others. Whereas once you get through to be experienced, if it's still giving you trouble, it's something that's worth addressing.
As I was talking to these people to get their definition of that. Then okay, that would be great. I could put that on a shelf to catalog those things and say, "These are the practices that people are concerned about." And it would be a pointless bit of academic stuff that the industry would never ever read or be the least interested in. So what I did was take that and put it into some workshops where I could share those ideas and get people to discuss those things in a way that they don't normally get around to discussing them, to get those issues recognized and addressed, and build some of that empathy that people have been talking about. There's a whole talk in the optimizing new track on Monday about empathy. It was mentioned in the keynote this morning.
And, finally, well, a bit of a spoiler alert here. I wouldn't be standing here telling you about if the whole thing had tanked and everyone had said it was horrible and it didn't work. So I'll be telling you the feedback I got from the companies I took it to saying how was this for them, did it work, was it useful?
Interviews
Let's start those interviews. I spoke to all these developers one to one. So it's kind of nice opportunity for them, actually, to be able to talk to somebody frankly, about the things that make their job easier or harder. It's easier to focus on the things that made the job hard. But I did also ask them what makes their job easier when somebody has stuff? I started off with open questions about, "Yes, just tell me about these things?" like I asked you at the beginning.
That only gets you so far. People do come up with some issues there. But they tend to be, because of the whole psychological process of memory, the most recent ones, the ones that you can bring to mind readily, or the ones that have the most emotional effect; the ones that you really remember because they really wound you up. I wanted to do more than look at that. I wanted you to look at the whole breadth of their career and help them to reflect on their entire experience, and to include not just coding, but things like what they're doing with bug fixing, things about build, things about how people interact with them across the whole breadth. Trying to think about whole developers’ working day, working week. It's not all sitting there typing code. So I wanted to make sure it focused wider than that.
What I had was actually cards to prompt them to do that, sort of cued recall things once I got them to come up with the ideas that emerged to them first. I had cards. You won't be able to see the content, obviously, but feel free to have a look afterwards. It's a set of cards, A6 size, each of them with a section on the top describing a peer behavior, and sometimes with an example underneath, not meant to be prescriptive, but just to help explain what the behavior at the top meant.
I asked them to sort these according to how much it impacts them. So not, “Is this good practice? Is this widely recognized in the industry? Is it a good or bad thing to do?”, but very personal individual self-centered questions about how does it affect me when somebody else does this? So the middle ones is neutral, kind of doesn't matter much in one way or the other. Good one, slight impact. It doesn't make a huge difference but when you see it, it brings a little smile over your face. And you go, "Oh, yes. Nice. The way they've done that." It gives you a hope, a nice little bit freewheeling downhill for a moment. The really important ones, the good noticeable impact ones. This is the kind of thing where maybe you go to a task, you think it might be a three-day job. It turns out to be a half-hour job, but someone's done a really nice job before you of setting things up so it's fluent and clearly understandable. And you can see exactly what you need to do.
Every silver lining has to have a cloud, right? So on the other side, the bad ones, with slight impact. This is the kind of thing where as an experienced programmer, you'd have a little sort of trip and a little of stumble along the way. You kind of scratch your head a bit, wrinkle your nose, and go, "Oh, that's a bit of crap." But then you move on and deal with it. You understand what to do. It's not difficult, I can't spell that, so it has to say "Bad. Slight impact." And, finally, the Voldemorts. The bad, the noticeable impact. So this is the converse. You think it's going to be a half-hour job, and it takes you three days or a week, or it's completely insoluble, because it's such a mess and you have to abandon the whole idea. These are the ones and you have quite a visceral effect with those.
I asked them to do this sort. I'm going to show you some examples quickly of the cards that came out in the frequency wise from this sort, in the top five or six. Now, we didn't just take quantitative numbers for the sorting of them. I'll explain why as we go through some of them and how important it was, that we afterwards then discussed them. So the ones they put in the Voldemort pile- I'm going to call that the Voldemort pile from now, and I haven't gone to that. I like that. Okay, so we discussed all the ones that they put in Voldemort pile and we talked about, "Okay, why is it that this is thing is bad? What is it? What impact does it have on you there?" And also what did we put in the other one? Maybe the Dumbledore pile, something for the good, noticeable impact.
We talked through those. So these are the top frequency ones from both sides of that. This was the top card of all. This was 89% of people put this on the Dumbledore pile. It is all right. We can stick with Dumbledore pile. It's so much easier than saying it's a good noticeable impact. Yes. So, immediately obvious from this, that this makes your job easier because all you have to do to repeat that task is press the button. Great. So clearly, it's easier.
This is one of the places where discussion came in as being important, because it's not just that it's easier to press the button, it's also that this is now executable documentation of how to do that task. So it gets tested. Every time you run this, you know that what they've written down about what they know, that information they had about how to build it is valuable, is useful, it’s not a Word document you can't test. You it works. So it's sharing of information. This is also sharing information. So this is including the symptoms in a bug report about how you got there. It's not just, “This thing is broken.” The person reporting the bug has probably the most information about it at that point. So they're writing down everything they know about what the symptoms are and how to make that bug appear or everything they know about it. You're losing me there? You are all right? I'm good? I'm sounding a bit funny. That's another piece of communicating the information that you have.
Sharing information. The opposite of fixing symptoms without discovering the root cause of a bug. You see the symptoms, you've got that information about what happens, and you do something. You don't really understand what's happening, but you managed to do something that sort of makes things carry on at work sort of okay. At that point, you've buried some information. You've hidden some information from people, just to kind of move things along quickly. So back to helping people again, sharing your knowledge, sharing the knowledge that you have, this is one of the things people employ you for. It's not just to do the job, it is also to share your knowledge and expertise with others in the team and spread what you know. So it also works the other way around. People who are good at helping others can also be ones who are willing to learn from others. And they'll discuss suggestions about their code. They're willing to listen. So it's not all about, "I'm the expert. I know everything," people who are very much willing- the good ones- to hear what you've got to say and be open to suggestions.
In contrast to the zealot who says, "There is one true way to do it," and is closed and dogmatic about it. It’s kind of my way or the highway. This is not necessarily always from a bad place, either. Sometimes people have learned at some point in their career that this is good thing to do and it's a good practice and they're trying to do something that's good practice. It's just that they're not sensitive to the context in which they're doing it, or things have moved on. Generally or quite often if they do this, it's not just that they're opinionated, it's that they care. It's not always a bad thing that they're wanting to do it, but they need to listen to more to the alternatives.
Sometimes these are the same ones who will be possessive and defensive about code. Now, this is another case where the discussion was important because there are two sides to this one. So taking some ownership of code, not a bad thing. Taking responsibility and caring about it, is a good thing. What's not a good thing is making yourself a really bad truck number. Are you familiar with truck numbers? It's the number of people who have to be run down by a truck before your project is in real trouble. Or more positive version of it, lottery number, number of people who have to have a massive win the lottery and leave your company. But there's a slightly more positive way of looking at it. Yes, or bus number, any of those.
So the people go, "No, I have to do that. I'm the expert on this. This is this is my area," and are defensive about it, are a problem because what you end up with is something that only they know about. Really bad truck number. And anybody else then coming to work on it or understand it or integrated with it is facing problems. These people are often also the ones who work in isolation. So, in some ways, you’d think at least they're leaving you alone. They're not interrupting you. But what they'll do is go off and sit in a corner and do something their own sweet way that doesn't necessarily fit in with how your team understands things. It doesn't fit into the project. It is kind of weird and different. And when somebody else does finally get to see what they've done, they then have to cope with the idiosyncrasies of it, rather than having to be able to discuss it along the way.
For example, people coming across shiny new things, suddenly there's this new framework. There's not even a discussion of, "We've got to try this," they'll go ahead and put it in there. We used to work with a guy who was a great one for that, when we used to call him, "I will tell you face-to-face. I won't tell you [inaudible 00:16:16]." So when you encounter code that's been written like this, it's hard to deal with. I also worked with a guy who was working on a machine - there's a whole issue about how this was allowed to happen in the first place - working quietly on a machine for three months before he actually checked anything in. And completely oblivious to the fact that the local machines that we were all working on weren't backed up and it was only if it's checked in that it was going to get backed up. So we had a lucky escape there, I have to tell you. But yes, it's not just about him, that's about the entire - that was my last job. No wonder I've ended up doing something else.
So going away and writing in isolation means you get something weird. This is a quote from one of my participants in the interviews. They came up with some really great words about this. It made me think, you know what? From the moment you've written something and anything you've written, it's kind of legacy of a sort. It's at least a constraint. Once something exists, that constraints what you can do from there. So this really made me consider what legacy meant. I suppose there's a specific meaning. But actually, the moment anything happens, there are constraints around you. So it's important kind of how it's done.
And this one, willing to ask questions. This is interesting too. This, again, is needed in the discussion. Because you think, some people are willing to ask you questions, isn’t that going to slow you down, that's going to interrupt you, that's a nuisance. Yes, it is. But potentially, if it's bad timing, but it means they're not working in a corner in isolation. So they're socializing their ideas, they're learning from other people, figuring out how things are done in the team. It means they're communicating, which is great. So this is why this one has come out big, even though it can take your time, it's time well worth spending.
Finally, this is the only one out of all - I've got 52 cards there. Quite a lot of them were about low-level coding details. I took them from textbooks on good practice. I took some of them from my own experience. I took some of them from respected people's tweets about the particular frustrations they were facing, including one guy who's a textbook author, who said, "Facing with tyranny of the to-do's. People do your to-do's." He says it's got things like art in there. There are quite a lot of things about the low-level details of code, about complex nested conditionals, the number of parameters that I was talking about earlier. None of those came out as a big thing. They didn't come out as neutral. And pretty much everything was a small good or a small bad, very few things are consistently neutral.
This is the only one of the low-level of code detail that mattered. I guess this is a grammar thing, isn't it? It's grammar versus vocabulary. So programming language syntax by definition and of necessity is unambiguous. So however weirdly somebody has used it, it only means one thing. It might take you a while to figure it out, so it might be a still a bad impact but not necessarily a noticeable big one because you can figure it out. I am picking it slowly but surely.
Identifiers, however, tell you what kind of thing is being operated on in that. If they don't make sense, there is no amount of experience that can tell you what they stand for. So we've probably got quite a lot of experience in here. Would anyone like to guess what any of these represent? So vegetables actually was a theme. Themes were a popular thing, people were reporting, I guess it's hard to think of variable names, good ones. So if you've got a theme, that helps you generate quite a few quite quickly. So you can call your variables broccoli and carrots and cabbage. Or, you can call them something meaningless like Wibble, because at least it's not misleadingly meaningful. You can see it's meaningless. It does what it says on the tin. That's an improvement actually over broccoli. Or, again, a themed one. Yes, naming them after "Star Trek" characters, like Spock. But yes, I have no idea what these represented and nor you. If I named them sensibly, you'd have a clue.
So quite colorful examples, these and that three weeks legacy system from my participants. I came up with some really nice words to explain the scenario. So I'd like to close the interview section by talking about what one of them said about somebody going off and working in a corner and doing their own sweet thing. And he said, "Then someone's written their own code, and reinvented the wheel and added an elephant onto it and a spaceship." A really nice example of somebody just building too much. That came up a lot. They're being stuff to wade through. They had very physical geographical metaphors for that, like macheting your way through a jungle of other people's code. Or digging your way through the weeds. Or fighting with a monster, particularly like the fighting with a monster one. I feel that one. I've had that experience.
Workshops
So what? I've got this list of things that people say are an issue to them, and I can share them and I stand up and present about them. But I'd like to do something more practical to help developers like I was, to actually benefit from these, maybe develop that empathy, understand how these things affect other people. So this is how I came up with the workshop idea, taking those really nice explanations of the "issue" and the participants, and the fact they've actually quite enjoyed this card sorting process. It's quite a nice way to stop and think about it and contemplate and nicely cued. I've put those together into a workshop format. I've tested this out. Well, I was interviewing experienced people. The workshops, I tested with mixed teams. So anything between four and seven developers, typically people working together. All sorts of amounts of experience.
I put onto the cards for the workshop, A4 cards, I took quotes from interview participants representative of the themes that emerged and I laid them out like this on a meeting room table at the participants site. So they'd come into the room and they'd see. So quite intrigued to see what's in there. And first step, I gave them some time to choose one. They have to pick, out of these 20-odd cards, one that really spoke to them, on that same question of, "How does it affect me when someone does this? Not good practice, but how does it affect me?" I gave them however long they needed to make their choice. It's during this I noticed something I came to think of as the pounce. So I'd have them spread out on the table in front of them, and they'd be looking through them. And suddenly, someone would go, "Oh," and grab one. And there'd be laughter or some kind of sign of recognition, a suddenly you could see one resonated with them.
Once everyone had picked one, the next task was for everybody in turn to explain to the entire group why they've chosen that one. So explain the impact on me. We had three rules for that. First off, no sacred cows. So no dogma here. No, “This is good practice. This is a good one because some luminary says so, this book says so.” It has got to be that personal impact. Secondly, I don't know if this one works across the Atlantic, no assumptions. So the dreadful pun with the donkey was also quite a nice icebreaker. So no assumptions. You must explain why it has impact. You can't pick one up and say, "Well, this one's obviously bad," or, "This one is obviously good." Next, essential to explain just how it affects you.
And finally, having said this is about how it affects you personally, you cannot be wrong about your own experience. Your own experience is your own experience. So nobody can come along and say, "No, it's not like that." Their experience may be different. Their mileage may vary. At which point you've got a nice cue for some discussion about why that is different. Or is it a context? Or something like that. But no steamrollering of somebody else's experience of these things.
Finally, some follow up so they knew what to do. It wasn't just a talking shop, this stuff just happens and then they carry on with their day job. Something to take forward to remember. Or at least that would be there in the rainbows and unicorns versions of this talk. Unfortunately, I didn't do that. I'm just interested really in whether or not I could get them to discuss these things and haven't thought about taking it forward. But it was something that came out in the feedback that it'd be useful to have. Hopefully, they learned something from it anyway, and would go forward. But it would be nice to have some kind of record of it, some kind of formal way of saying, "Okay, we are going to now learn something from this and do something with it”, rather than it just being over and that's the end.
However, from my observations of what went on, it did work as in terms of that discussion. What I noticed every time, was people would start off addressing themselves to me as the researcher. So I'd pick up their card and read through, start going around the table, everyone having their say. And the first person will be reading out their card to me and explaining to me. But pretty quickly, they were turning to each other and discussing. They were naming particular components in their system, particular issues that they had in terms that would make sense to rest of our team and actually having a discussion. And I could just sit back and watch the team discuss, having prompted them to talk about this thing, which is lovely.
They were coming up with solutions as well. So they identified some problems that they could actually solve. They were stopping and looking back and said, "Yes, there are ways of doing this and we're not doing it and we could." Or sometimes there are ways of doing this but it's not practical here because - at least they'd address it.
Feedback
So finally, what did they say about it in the feedback? I asked them immediately after the workshops, what did they think? Then I gave them a month and ask them again a month later, to reflect on it and see if it had actually made any difference to them and was taking them anywhere. I asked them, would they recommend it to others? Ninety six percent said yes. And actually, the ones who weren't in that 96% said maybe or possibly. It wasn't actually a no. They said things like this, "It stimulates interesting discussions within the team." The important bit here, I think, is the “not usually or traditionally talked about”. So these were communicative teams. They were good teams. I don't think a team that wasn't working well would have allowed me in and invited me in. You've got to already be interested in your practice to do this in the first place.
What they said is, yes, they're having discussions, but their talk is often focused on the work to be done. So you're looking back about maybe what happened last time and what you could fix in previous sprint, or looking forward to what you're going to do next, or dealing with the immediate problem in front of you, but not getting much opportunity for that bird's eye view to overlook your practice from a high level and try and do some fire prevention of those problems, rather than actually firefighting the problems when they can come up in front of you.
I asked them if they'll reuse it. A slightly lower number because some said, "Well, kind of no. We've done it now and we don't need to do it again." But a lot said, "Yes, it being useful as an annual thing to catch up when new people come on the team," or, "Yes, it would be nice to reuse it." It was a useful chance to reflect. Again, it was about that process to be able to do it. This is an opportunity to do that reflection. They didn't have anything in their process to actually help them do this kind of reflection to improve their process overall. "So as a team," one of them said, "we have no rituals which attempt to improve consistency." So they'd want to improve but didn't have this particular scope to do it.
And finally asked them about other uses. I asked them specifically about appraisals. And one person said, "Yes", one person who is more managementy, said, "Yes, it would be useful to have a checklist." A lot of people with that one said, "We kind of don't know. It's not really my job," sort of thing. A lot of people mentioned how it'd be useful to broach things with other teams because this is a nice psychologically safe way of doing it. These quotes all come from real developers, but real developers in other companies. So you don't have to say, "I really hate it when Sangeeta does this," or, "I really hate it when Gail does this." You can just pick a card. You know it's a common theme from real experienced developers, and you can say, "When this happens, it's a problem because …" You know it's a genuine issue across the industry and it's not personal. So it's a nice way of raising those issues. There are also a lot of people saying, "Yes, we have other teams that we need these conversations with to open up that discussion."
Recruitment was another one I asked them about because I thought this would be potentially an interesting way of looking at how candidates think, or maybe seeing how they get on with the team if you did the workshop process with them. So somebody said yes to this one. "It could help get insights into how the interviewee would fit in team working." Now, it wasn't clear. I didn't ask them specifically, "How would you use it in recruitment?" So I don't know whether they meant they would do the workshop, or they'd just use those card materials in an interview scenario. But I have talked to a person I met at another conference about using it for recruitment because he was planning to do some shortly. He hasn't tried it yet. He suggested it would be a useful way to get into rather than, "Why did they do that?", or, "How are they thinking?" sort of thing for interviewees.
So what he said was this gives them choice. “What I believe this technique offers that I had certainly not considered before is choice.” So rather than asking the question based on his own experience, which might not chime with things they've done before, just because of the particular route they've taken to there, it gives them the opportunity to pick, maybe give them a few cards to choose from, and ask them to pick one or two that resonates with them. Explain why. You get some insight into their experience and how they approach things, without you having to confront them with something that maybe they haven't got much of a thought about.
It's hard sometimes to spot that that's happened and hard to recover from it, because it puts them on the back foot. "Oh, actually, I've not done that." And it's kind of an awkward moment. It also means that it's kind of not so scary answering that. There's no kind of right answer with it. No, which one you pick it up to you. It's only got to be the right answer for you.
So that's why I'm here. I'd like to offer you an invitation to try the same sort of thing, probably with some refinements to make sure there's some kind of recording and forward action that comes from it. If you've experienced this scenario, and you're interested in these and think it might have some mileage, or if you're not quite sure, but you like this thought from one of my participants, who said, "We're not thinking in these ways," and you'd like to try this as a way of thinking in these ways, please give me a card, or an email, or a tweet, let me know and you can give it a go.
Questions & Answers
Participant 1: Have you landed on a standard set of questions that you just think cover the whole gamut? Or are they evolving?
Ollis: Absolutely. The workshop? The workshop cards came out of the themes from the interviews. So you wouldn't necessarily have to use those questions. I think you could use the same format, provided you know these have come from a respectable source. It's still quite a nice format to be able to sift through them and just pick one and everybody gets a chance to talk. So it doesn't have to be these particular questions, other than what they do have is that backup of this is a whole load of experienced people in there. But yes, you could tune them to specific issues that you wanted to address.
Participant 2: Maybe to rephrase, I think what he was asking, have you made these questions publicly available?
Ollis: Yes, I could do.
Participant 2: I think that would be super useful.
Ollis: Yes, I can do that. I also have them up here. If you'd like to have a look through, feel free.
Participant 3: Hey, this isn't necessarily related directly to the workshop. But generally, in terms of creating a feedback loop and people being comfortable with that, do you find that there's a common interval or cadence that works best for trying to get this feedback? Because, doing a sprint for every retro is good. But sometimes a longer-term retrospective might work and we tried doing quarterly retros. But I found sometimes people think that's too short of a gap, but sometimes it's too long. In your experience doing this, is there a common pattern you'd say for that?
Ollis: I think it would depend on your circumstances and the sort of work you're doing. This only took an hour to do for them to stop. You wouldn't want to do it every week because your situation wouldn't be changed. Yes, it is that bigger overview. Again, it might actually work for quarterly. One company was suggesting they would like to do it annually and when new people come on board because it's a good way of sharing the ethos of the team and their approach to the work. So does that help? Does that answer your question?
Participant 3: Yes, it does.
Ollis: Oh, so you're there.
Participant 4: That was a good question. It’s kind of similar to what I was going to ask them. We cover a lot of this stuff in our sprint retros and I was just wondering if the experience opens the team up to how they're feeling without being direct with people, I'm trying to understand are people not feeling like they're in a safe place and this gives them that psychological safety to talk about these things?
Ollis: Yes. I think it's two things. One, it gives them a psychological safety because it’s diffused by it being - this is a predefined set of stuff. One person did say, "It'd be nice if we can raise our own thoughts in there." I thought, "You know what? That's not what you want to do because then this becomes a squabble." You might want to refine the set of materials that go into a workshop to suit your location. But the moment it starts being somebody talking about what happens here and they've raised it from here, you lose that psychological safety, I think. But these were teams that would communicate about stuff, anyway. They were quite open teams. So they really didn't have an issue with that. Some would, but these ones didn't.
But what they didn't seem to have was the space and the facilitator. A lot of them did say having a facilitator there to do it, just to help them step back and focus on this bigger picture thing, rather than the immediate “This is the problem we've got”, was a thing that really helped them. They've kind of felt on a day-to-day basis, we’re problem solvers. They're getting on with solving immediate problems but not solving the thing that causes that problem. I think, to be honest, just giving people time and space to have that reflection would be good, but then having someone facilitating them to do it means you get good value out of that time.
Participant 5: My question is about, did you see any differences between different industries or different languages in the answers you got? Can the results of your PhD study feed back into some best practices for those languages?
Ollis: No, I expected it to. And my small cards had some stuff and then the things about exceptions in there, and some things actually turned out to be specific particular paradigms, which is a mistake. But those weren't things that were a big issue for people. It surprised me, which convinces me that I was probably paying attention. Because I was thinking about those small things if sort of [inaudible 00:37:52] exceptions or that kind of thing. That's an annoyance. But it turns out not to be anywhere near as bad as creating that monster that you have to wrestle by going working in the corner. It's almost like a building Frankenstein's monster in the corner and then everybody else has to fight off that monster afterwards. So oddly, I think you could still use a similar format and focus on those things, if those were the issues you wanted to deal with. But to my surprise, those weren't the ones that came out.
Participant 6: I like the idea of having a facilitated discussion. I was wondering, do you have any tips or guidelines for a facilitator to run these workshops?
Ollis: This is quite an interesting one for me because it's really hard not to get involved, because I've got a development background. I mostly managed to stay out of it. But on the very last one, I was actually in there with a suggestion. But it was nice because it felt like it really was a normal software developer discussion. But I think, basically, make sure those rules are followed. I didn't actually have any problems with the rules. I think having the little cues out probably helped, people who are paying attention. Not me just standing out with a slide with a load of rules. I had a plastic cow or a plastic donkey and bit of Lego, and you get everyone's attention when you've got a bit of Lego. So setting the rules clearly, having that process of everybody saying their piece, and then letting the discussion happen from there.
Occasionally when they were discussing a thing, I would just prompt them and say, "Is there something you could do about that?" So it would help them with that. That was pretty much it, because these were already pretty good teams. I did some pre-work finding out what kind of state they were in, whether they were forming, storming, norming, or performing teams. And surprise, surprise, nobody who was in a really bad state was actually signing up for this. It was people who were in a good performing state. All I did, it was just a case of giving them a little structure of that discussion, that helped them to step back and reflect from what they would normally do by themselves. Does that answer your question? Okay.
Participant 7: So are these all very developer-centric questions? Or how well would it work with more of a cross-functional team, where you have testers, product people, designers, all working together?
Ollis: Yes, I think there's a mix in there and because it's not those language-specific things; quite a lot of it would work for those cross-functional questions. I think there might be, depending on the scenario, you might want to gather ideas and broaden it a bit to have that. Maybe you get some feedback from testers across a whole load of companies and say, “What are our issues as testers?" and mix those in together if you want. So it's not all one side's issues in there.
But as it stands, I think it'd be interesting to try it and to see how far it goes and how much it makes sense to people. Wave the cards under the nose of the people you want to talk to and go, "Do any of these mean anything to you?" Because it's sometimes like the bug reports for example, some people are talking about those in terms of, "No, it's not so bad if your developer is doing something.” I’ll just walk around the corner and tap you on the shoulder. But there are people a bit more remote in support, for example, who are not seeing who is picking things up and then reporting things, and so they are on two sides of the same processor. So, yes, I think it one of those “it depends” answers, but I they're scoped to tailor it towards that to suit your needs.
See more presentations with transcripts
