Better software through shared understanding

This talk takes a step back from the toolbox to ask:  What are the core benefits a tool should provide?

As a project grows up, it has different needs and benefits from differing levels of "discipline".  Likewise, people have differing comfort levels for process rigor.

Too often we focus on the laundry list of benefits that we might get from a tool without considering the maturity of our project or the composition of the team. We want to build shared understanding without dictating a process that crushes diverse thought and collaboration.

This talk proposes examples as a universal way to build shared understanding without tying a team to specific tools or implementations.

The video above was recorded at ConFoo.ca on March 10, 2017.

Transcript of the talk

[00:00:00] Good morning. Thank you all for being here. I appreciate you. The title of this talk is now, Better Software Through Shared Understanding. My name is Steve Jackson. I'm a double agent at Test Double. That's my Twitter handle and my email. And I really look forward to hearing from you if you have any thoughts about this talk.

‍

[00:00:19] So, I have a lot of ideas about the tools and processes that we use for defining the work that we do. Things like requirements and stories and wireframes. But the more I thought about it, I realized that a lot of times we kind of pick our tools arbitrarily without thinking about What part of the software life stage that our project is in and then I realized we don't really have a good way to talk About this lot the stages of life that your project might go through so I want to start there So as I see it the first stage here's the big idea, right?

‍

[00:00:55] This is where our ninjas and our rock stars hang out. They hack something together and they're really excited about it And then we might say at this point, you have a solution looking for a problem. But that, that's probably not fair. They have a solution to a real problem. It's more accurate to say, we have a solution that's looking for users.

‍

[00:01:12] Who cares about this thing? Who's really going to get excited about it? And once we sort of find that, we can move into stage two. And this is all about how do we take this idea and keep it moving? How do we get releases together? How does our team do things? How do we form? What does it mean to be part of this project?

‍

[00:01:31] And we start to define those things, we start to come up with norms and conventions for our team, and then we start to codify some of those decisions and tools. And then once we do that, we enter the third stage, which is the hyperproductive stage, where we're just shipping features all the time. And our focus switches to, what are we going to build next?

‍

[00:01:49] What else can we do to make our users even more excited about this project? And this is where we start making money.

‍

[00:02:01] And then, eventually, projects go into stage four, and I think of this as like the maintenance mode. Hyperproductive. Where we've got this thing that continues to make money, and we want to sort of keep it going, but we've kind of run out of ideas. Or maybe our new ideas, we're not really sure how to build them on top of what we already have.

‍

[00:02:21] And product companies kind of understand this. We start with a project idea, and people start to get excited about it, and the interest goes up and up and up, and then it starts to kind of level out, and now people don't care. Oh, so we start a new project, and now we're all really excited about the company again.

‍

[00:02:37] Microsoft Mechanics And you look at something like Google and they've got projects and all these different stages that all the time they have autonomous cars and stage one Android might be something like stage three and then like search and Gmail or obviously stage four projects. So kind of the way this seems to flow is that we start with the idea and stage one and then we start to build norms and rules and conventions around it.

‍

[00:03:02] And this naturally leads us to tools so we can be more productive. And then those tools start to control us a little bit. And so we start to have a backlash against those things. Now I can pick a lot of different examples of projects and programming languages and things, but I'm going to pick on Node.

‍

[00:03:19] js for a minute. So Node. js started with this idea. Hey, I can do this event loop async I O thing. And by the way, you could do it in JavaScript. And everybody's kind of like, okay, that's interesting, I guess. But, people started getting on board, going okay, that means I can do JavaScript on the server, and I can start piping operations together, that's kind of cool.

‍

[00:03:42] And so people started to join the community. And then at that point, you start talking about what it means to be in a Node project. And in Node, we build all of our things from smaller things. They're all built on top of each other. And so now we're starting to talk about dependency management. And to be effective in Node, you need to use NPM.

‍

[00:03:59] And we spend a lot of time worrying about that sort of thing. We start talking about semantic versioning and things like that. But now once these tools are in place, now I can start a Node project and be productive pretty quickly. I have all these tools that help me be successful. But then we figure out that, oh, people don't really understand semantic versioning or perhaps care about it at all.

‍

[00:04:20] And so, if you want working software in JavaScript, you have to have the latest bleeding edge version. Because we're not going to backport security fixes or anything like that. That would be crazy. So then we start building tools like Greenkeeper. So now we have a way to make sure that our releases are good, but now we have these new gates in place.

‍

[00:04:42] I can't release my software unless everything I depend on is also working and up to the latest version and all these other things. And this is where our pointy haired bosses start getting involved and they make rules like you shall not release unless we pass all of these checkpoints. Things like that.

‍

[00:04:56] And maybe Node will start to feel a backlash from that sort of thinking. But if we zoom out, we can see that JavaScript has followed this whole life death rebirth cycle for 20 years. JavaScript started in 1995. It was built in 10 days by Netscape. By the time I started writing JavaScript in 1999, I feel like we were starting to peak and we had fragmentation because Internet Explorer had a different version of JavaScript that wasn't copied very well.

‍

[00:05:26] But I wrote this sweet drop down menu system in IE 5 that looked amazing. It didn't work at all in Netscape. So my project got canned. And so I said this JavaScript is stupid anyway, it can't do anything, so I'll go work server and fat clients and stuff like that. And I feel like a lot of people followed me, maybe, I don't know.

‍

[00:05:46] But around 2006, we got excited about JavaScript again. We've got jQuery, we've got AJAX, we're talking Web 2. 0. If you were on Stack Overflow in the early days, the entire front page was JavaScript questions and how can I use even more jQuery to make amazing things happen. That was the answer to every single question was more jQuery.

‍

[00:06:07] And then in 2010 we said, Ah! There's too much jQuery! I can't, I can't do anything! This is crazy! So we started building all these MVC frameworks. The Backbones, and the Knockouts, and the Angular, and the Embers. And now we've got React, which I think is transitioning into stage 3, if we've decided that Redux is really the thing.

‍

[00:06:27] Maybe, we'll find out next year. But you can see that this path continues to just keep going up and up and up, and JavaScript is way more popular now than it was 20 years ago. So if you can sort of figure out these troughs, you can continue to build excitement about your project, even when you have the small setbacks.

‍

[00:06:45] And everything just keeps going up and up. So, I was trying to think about this in terms of projects, and is there like an ideal spot on this scale you want to be? It feels like at 4 you're starting to sort of dive down and that's not so good. But then I thought about it and it seems like, okay, well if I'm a commercial project, stage 3 is where I want to be.

‍

[00:07:07] This is where my users are continually asking for more features and are willing to pay me more money, so I'm going to keep adding more and more stuff. But an open source project probably wants to be in phase, stage two. Because this is when people are talking about your project and trying to figure out how I include it with my project.

‍

[00:07:24] And there's a lot of interest around what's going on. So it's interesting to me that there isn't really a universal place where all projects should try to strive to be.

‍

[00:07:36] And then I thought about this and it's not just technologies. It's not just projects. It's people too. Think about where you fit on this timeline. Where do you feel interested, and fulfilled, and productive, and valued? Are you a stage one kind of person? Are you always hacking together new ideas, full of new designs, and always sketching out new things and trying them out?

‍

[00:08:01] Are you a phase two kind of person? Do you like laying the groundwork for people to come behind? Are you talking about testing strategy, and continuous integration, and things like that? Are you a phase 3 kind of person? Are you like, well these are just all tools, I just want to be productive, I want to keep delivering value, and I really just kind of get upset when my tools don't do what I expect them to do.

‍

[00:08:26] Are you a phase 4 kind of person? Are you a natural caretaker? Are you looking out for the users you already have, and you want to keep things running smoothly?

‍

[00:08:37] Now, me personally, I'm a late to kind of person, so I love talking test strategy, I love automating builds, that makes me happy. And I'm pretty okay in phase three, like I can crank features for a while before I get bored. But notice this is the middle of the scale, and it's my scale, so it's entirely possible I'm biased here.

‍

[00:08:57] And I'd love to hear if you have other perspectives. And the thing is, I want to work with people all over this scale. I love working with 1s. They're so innovative. You can't give them a problem they won't try to find a way out of. That's great. I love talking to 2s. They like the same stuff I do. We'll talk about test strategy and automation and everything else for days.

‍

[00:09:20] 3s are great. They're focused on delivering business value. They want to be productive. I always look at 3s, they're like my canaries in the coal mine. If they're not happy, there's a problem with this project. We need to do something. And then I like fours. They think more strategically. They're looking out for the users.

‍

[00:09:38] They often spot the problems that are completely going to sink our project and want to do something about it.

‍

[00:09:46] So the challenge I have is like, how do we create a place where all of these different people can feel interested and fulfilled and enjoy their environment? It seems to me there are two sort of obvious options. First one is we split everybody up. We let the ones come up with new project ideas. And then they pass those off to the twos, and well, they're probably bored now, so they'll start a new project idea.

‍

[00:10:14] And we'll just keep it going. We'll pass the two project along to the threes, and then along to the fours. And after a while, it'll start to look like this.

‍

[00:10:26] But look at this! Look at all these projects! We're probably doing pretty well, right? How do the people in this picture sort of feel? Well, the ones are probably pretty happy. This is sort of an ideal environment for them. They just come up with new ideas and ship it off, and they're probably the top performers, and they feel really good about themselves.

‍

[00:10:46] The twos are happy for a while, but they start to get sad, because that three weeks they spent on building the perfect automation test suite just doesn't get run anymore, and nobody cares on all these projects that have made it to phase four. The phase threes are overworked. They've been hyperproductive forever.

‍

[00:11:02] They never get to take a break and go off to conferences and learn new things or try different stuff. And the fours hate everybody. They get to clean up after everybody's nonsense that's been put on them. They're constantly putting out fires and they feel like they've spent their entire lives trying to keep the company from going under.

‍

[00:11:23] But hey, this is a successful product company! Look at all those products. They've made so much money. That's great.

‍

[00:11:33] I think more than the happiness factor, maybe equally so, the thing that bothers me about this is that the teams become little monocultures. Every time a problem is encountered, they're gonna try to solve it the same way. The ones are always gonna try to hack more code. The threes are always going to look for a new tool.

‍

[00:11:51] The twos are always going to try to build a new tool. They're lacking in diversity. As an industry, we are finally starting to come to grips with the idea that, Hey, it would be nice if everybody didn't look like me. We need diversity across all the different spectrums. We needed gender, and ethnicity, and race, and sex, and age, and everything else.

‍

[00:12:16] Because when everybody looks like me, bad things happen. Laughter. Google Photos and Flickr in 2015 both started auto tagging black people as gorillas. When the airbag was first invented it killed dozens of women and children because it was perfectly set up for the average American man. Voice recognition was invented in the 80s and immediately flopped because it couldn't understand the female voice and that was 95 percent of the target market.

‍

[00:12:51] Teams that are homogenous lose out on these perspectives. Their overall group intelligence goes down, their performance goes down. There's tons of studies around this. The problem is that everybody feels like they're objective and rational, and that they make good decisions. But I feel like techies are really bad about this.

‍

[00:13:11] Like, we think because we work with computers, we're somehow more logical than everyone else. But all of these studies keep proving that humans are just terrible at noticing our biases, or even acknowledging them when they've been pointed out to us. We're able to come up with an excuse instantly, without conscious thought, about why that doesn't apply to me, and it doesn't matter.

‍

[00:13:34] We can't know all our biases, and we can't clear away all these false perspectives. We need outside help. Contrary to what I believe, T Pain did not create Autotune. It was actually this guy, Andy Hildebrand. He's a seismologist from Exxon. The Harvard Business School did a study where they crowdsourced the number of problems in various domains.

‍

[00:14:00] Very complex problems. And what they found was that people's whose domain of expertise was six degrees removed from the problem domain were three times more likely to come up with the correct solution. What this tells me is that the sort of problems that a stage one software project runs into probably should not be solved by stage one software developers.

‍

[00:14:24] So what's our other option? Oh, you just dump everybody together, right? Let's see how that goes.

‍

[00:14:33] If we look at our stages again, we can say that the first stage is all about adding new functionality. I don't care what we made last week. It doesn't have any users anyway. Let's throw it away and start over. Phase 2 is about stabilizing what we have, so that we can move to stage 3 and add some more. And then we add things and things keep breaking, so now we start working on stabilizing again.

‍

[00:14:59] So maybe thinking about this linearly isn't really the way to do it. Is it two cosmic forces that are constantly pulling us between capabilities or working on sustainability? Now left to our own preferences. The 1's and 3's are always going to want to add new software. And the 2's and 4's are always going to want to try to solidify what we already have.

‍

[00:15:25] We need something a little bit higher to help us all pull together and create an environment where we all feel like we can contribute.

‍

[00:15:34] If we look at our phases again, I think each one is defined by a question that needs to be answered before you can move on to the next phase. In the first phase, that's who? Who are my users? Who cares about this thing? In the second phase, it's how? How do we keep this going? How do we make releases? When we figure that out, we can move into what?

‍

[00:15:57] What are we going to build next? What's the next great thing that we're going to do? And then phase four is all about predictability. When are we going to do our next release? When are we going to fix this bug? And the overarching question I think that we could apply at any point is why? Why are we building this feature?

‍

[00:16:19] Why are we building this project? Why does this team exist? Why does our company exist? What are we here for? I think it's interesting because Agile methodology spent a lot of time thinking about this why. And it's promoted things like user stories so that we would remember that of course when we build features they're for people.

‍

[00:16:39] That's why we do it. But what happened with Agile? It started with some principles and norms and ideas. And then it turned into tools, solidifying those norms. And then it started to control us. And now there's a backlash to the point where you may not want to be agile anymore.

‍

[00:17:03] We need something where we can come together. We need to be able to take all these different perspectives and actually understand what each other are saying. Now this isn't easy. This is going to involve actually talking to people and being open to changing our minds. We don't all think alike. So we have to be willing to entertain other perspectives and modify our thinking based on that.

‍

[00:17:33] So what does it look like if we actually get it right? What does a diverse team look like that's working well? The team comes together when there are problems. They don't spend a lot of time split up amongst roles. They have some idea of who is working on the most important thing. They have some idea of what the most important thing is.

‍

[00:17:55] That's probably the most important thing. And then they have some idea of what to do about that. So if Jane is working on the most important feature, and I'm working on the seventh most important feature, I need to be a little more flexible. With the way I treat myself. Like, I may have made a commitment that I'd finish this thing today, and that's very important to me because I said I would do it.

‍

[00:18:18] But if I can help, I need to be willing to do so. I'm not working on the most important thing right now, and people aren't trying to waste my time if they have a question. If QA has a question about a feature, that's automatically more important than anything I'm doing right now. Because that happened first.

‍

[00:18:34] It needs to get to production, it needs to get fixed. It's more important than this new feature I want to add. Even though, as a developer, I would much rather be hacking on this new feature. I really need to be able to gain an empathy for the people I'm working with. Sometimes that's hard. So the shortcut I usually suggest to people is to get involved with your users.

‍

[00:18:55] As a person on a software team, you have the unique ability to change the way that people feel about your project. That's powerful. So, if you can get involved with user research, do that. Like, I'm not a UX expert, but I can listen, I can take notes. If you can do support for a week, find out all the little tiny things that drive your users crazy, you might be able to help with.

‍

[00:19:19] Support is always missing tools that would make their lives much easier, and if you're in a software development team, you might be able to help with. I worked on a project for the United States Navy for four years, and towards the end of that project, we did a big integration test. Onboard the Harry s Truman.

‍

[00:19:37] I spent two weeks out at sea and I learned more in those two weeks than I learned over the entire four years of the project actually working with my sailors using the systems they had to use and invalidated months of our development effort. We built all kinds of stuff they couldn't possibly use, need to talk to our users.

‍

[00:20:01] So again, because we all think differently, we need to get better about saying what's actually inside our heads. We need to be able to radiate the assumptions we have. This feels kind of silly sometimes. I'm going to go off and work on the login page, okay? We don't really need to talk about that.

‍

[00:20:17] Everybody's seen a login page before. So I go off and I make the login page, username, password, sign in, great. Some of this room right now is going, no, no, no, no, no more usernames. Make it an email. Some of us is like, username, email, man, OAuth, push that off on Google or Facebook. Why would you write another auth system?

‍

[00:20:36] Someone else might be concerned that I forgot the reset password link. Two minutes of saying what I thought we should do right here would have helped us create a page that everyone found useful, and that matched our team's goals. Once we get our assumptions out there, we have to be comfortable questioning them, and letting other people question them.

‍

[00:20:58] Again, they have a different perspective. They might have a different way of looking at this. So just to bring it back to login, I worked on another project, a web app, and we never built login for it. Which I feel is a fundamental thing of all web apps. You have to have a login, right? But this was an internal facing app with like 50 users.

‍

[00:21:16] They picked their name from the list, they could see their files. And it worked really well for them because they already had the workflow that if you went on vacation, someone else would do your files for you. So I could just pick Samantha's name from the list and I could work her files. And not only did we not have to build login, we didn't have to build some sort of vacation feature, or file ownership transfer feature, or anything like that.

‍

[00:21:41] Start by questioning that assumption. I don't know about you, but I come to conferences a lot of times so I can learn about new tools, new tricks that I might be able to take back with me. So I kind of want to help with that if I can. But the thing is, I get kind of nervous when I talk about tools.

‍

[00:21:59] Because I feel like sometimes the things that come out of those tools, those artifacts that we produce, become just as important to us as our users or the software. Which is crazy. But we tend to hold on pretty tight to these things. And I think that a lot of times like going through the process is useful like building a backlog is a useful process We get to talk about prioritization.

‍

[00:22:23] We get to talk about trade offs, but 90 percent of that backlog is worthless So I think my ideal is that we use these artifacts to kind of help us come together and then Through the fire of building a shared understanding, it emerges from the ashes in sort of a magical, mystic way. I think that's my ideal.

‍

[00:22:44] But, you can make the argument that, Well, what about the people that work there? What about the people that come on later? Surely they need to know what we talked about, what we decided on. Yeah, maybe. I think so. But, I've worked at places where it's like, Yeah, just go Google Drive. Have you ever looked for something in Google Drive or SharePoint?

‍

[00:23:05] If you don't know exactly what the name of that file is, you have no chance of finding it. So if you could take five minutes and actually help me find the file, I'm not trying to waste your time. Maybe give me a little outline. I can start to get enough context that I can add my own perspective to what we're trying to accomplish here.

‍

[00:23:29] As I started thinking through tools, I realized that I don't like tools as they become more controlling and towards the end, right? Death by specification was the original title here. And I, but I started thinking about this and it seems fair that in the beginning we want our tools and processes to be pretty loose that we can change pretty quickly.

‍

[00:23:53] But by the time we get towards the end of a project, it's probably fair for those tools to be a little more binding. If I'm working on a mature application. It is a reasonable expectation that every feature I add works in web, works in mobile, does all the logging we expect, sends the right things to the metrics server, things like that.

‍

[00:24:13] And a lot of the tools that we use in these very mature projects are all around making sure we don't forget all of these exceptions. All of these assumptions that are built into our software now.

‍

[00:24:25] And all the tools, I decided that maybe it's my bias, like all the tools I like are really designed to keep projects from going into stage 4. Because I like my software to be soft. I want it to be easy to change. That's what makes me happy. But the natural tendency of projects is to go towards stage 4.

‍

[00:24:44] And a stage 4 project is a successful project. It's made enough money to keep us all employed up to this point. That's pretty good. So maybe I need to take a step back and think about this some more. So in the last year, I've had the opportunity to work on a project of each of these types. I did the MVP, where we had a month to deliver a product, put it in front of users, see what they think.

‍

[00:25:09] I've done a rewrite, which is the quintessential Stage 2 project. We've got all the users we could possibly want. Now our big concern is, how do we do this so we don't have to do another rewrite next year? I worked on a more mature project, where my parent and I were adding three or five features a week.

‍

[00:25:25] and delighting our users and that felt great. And then I worked on a project that was doing a pretty good job writing this capability sustainability seesaw. They have market pressures where they have to continually add new features to keep up. But after they add those features, they take some time to build some sustainability in and re evaluate where they're at.

‍

[00:25:46] They've done this successfully for years. So I think one of the questions we should ask is Are the tools we're using right now helping us answer that key question we need to answer to move forward? If we're talking about release planning in stage one, that's crazy. You may not have a project next week.

‍

[00:26:06] Likewise, if we're trying to figure out continuous integration in phase four, that's also an obvious problem.

‍

[00:26:16] Howard Hughes went to his engineering team and said, I would like a steam powered car that can go from Los Angeles to San Francisco on one tank of water. And it was pretty ingenious what they did. In order to hold enough water, his team put pipes all through the car so that it could make it. And Howard Hughes saw this prototype and said, Well, what would happen to the person inside, If it got into an accident, well they'd be boiled alive, they're inside a giant radiator.

‍

[00:26:48] And he allegedly got so upset that they cut up the prototype into pieces no bigger than three inches square. Now you can take a few lessons from this. One, you could say, well maybe Howard should have been more involved in this project. Maybe, but he's a busy, important guy. You could say that hey, he should have written all the requirements up front.

‍

[00:27:08] But this was the first time anyone's really tried to do this before. That's kind of hard to do. And I feel like software usually falls into this qual this, this category. There's something unique about every piece of software that's being written. If not, you should not write it. You should go buy the copy.

‍

[00:27:24] Copies are cheap. Software is really expensive. The lesson I take is, I wonder if Howard had used an example of someone getting into this car and driving it somewhere. Because I could see as an engineering team just taking this as a challenge. Could it be done? Not should people actually drive in it. So much like the bindingness of our tools, I feel like our tools potentially work on this continuum between very abstract and far more concrete.

‍

[00:27:58] And I think that as we make things a little more concrete, interesting things start to happen. An idea is a very abstract thing. Build me a steam powered car. I could take that a lot of different directions. Take me a steam, build me a steam powered car that's safe. is an entirely different thing. And if I could build an example, using a more concrete example of someone getting into the car, that might help.

‍

[00:28:21] Funny things happen when we make physical things and put them places. They promote conversation in ways I don't really understand, but I'm fully okay with taking advantage of. So this is a vending machine. We're working on vending machine software, and we were having a hard time with this one feature that involves split payment.

‍

[00:28:42] And every time the development team thought about this, we're like, man, this is going to add so much complexity. And we try to explain it to the business and they were just kind of like, it's just a thing that you do. Don't worry about it. And so Nicole here cut pictures out of a magazine, put some prices on it and had our product owner come walk through the example with us.

‍

[00:29:01] Like, okay, I walked up to this machine. I see a Snickers is 75 cents. I got 45 cents in my pocket. I'm going to put 45 cents into the machine and then swipe a credit card. And our product owner sort of then finally understood that we didn't know why this thing was being built and she could articulate the reason that made sense, which was great.

‍

[00:29:22] We built a shared understanding around this. Potentially even better, as she was articulating it, she realized that, oh, that really only affects a very small part of my user base. And if it's as complicated as we're saying it's going to be, maybe we could defer that. Hey, win win.

‍

[00:29:42] I was really kind of skeptical about this when I first started doing it. Uh, everyone in my family is an amazing artist and I'm not. You kind of saw my curves before I hand drew those very nicely. Um, but my, as my friend Nicole says, like, if you can draw some boxes, you can draw a line. You can, you can handle this.

‍

[00:30:01] So the idea behind collaborative sketching is that a team, and probably the stakeholders get together in a room and they talk a little bit about a feature or they talk about a particular product, and then everybody draws what they think. It looks like the user interface for whatever makes sense, and it's amazing what happens.

‍

[00:30:20] Once we have all these ideas out here, we find out that it's not only the rockstar designer that has amazing design ideas. Like, everyone has used software before. They can contribute to this. And as we start pulling features from different people, it becomes a very collaborative sort of thing. And I start to feel more ownership over this thing because it uses my cool little widget that I like over here.

‍

[00:30:43] It's really cool. Has everybody seen this before? I call it the tire swing cartoon. It's been around since at least the 80s. Um, And it's funny because it's true, right? This is what happens, we all have different expectations of what software is going to do and we're all disappointed. Uh, but I can't help but think at this point, like, if those ten people had gotten into a room and drawn what they thought this would look like, they probably would have walked out with a tire swing.

‍

[00:31:16] So I think the first question to ask is, are the tools we're using still appropriate for the stage we're in? Especially as we transition to a new stage. I had a number of really great experiences using Cucumber. We were using it to build a shared understanding and it felt really good to have people understand why we were building different features.

‍

[00:31:36] So I would take this to other projects and be like, Guys, this Cucumber thing is awesome. We all should do this. And it didn't work so well. And what I've come to realize is that Cucumber is a pretty nice stage 3 tool. But in stage 1, it's kind of crazy to be talking about acceptance criteria. And what are things going to look like when we're going to change it tomorrow.

‍

[00:31:57] And by stage 4, it's almost necessarily changed into a regression suite. Because that will help me feel safer about the stability of my software in phase 4. Something like collaborative sketching is really great in phase 1. But by phase three, our product is so well defined that it's hard to reset to a blank slate and really get new innovative ideas.

‍

[00:32:24] My other criteria would be like, is this thing still helping us stay together? Is it good for our collaboration? I've been on teams where we've abandoned user stories because we've already internalized what it meant. Of course, we're building features for users. I don't need to go through the ceremony of, as a, I want to, so that.

‍

[00:32:42] So we just kind of put it aside and it worked well for us.

‍

[00:32:48] I really like examples because they are a little more concrete than just the abstract idea. And when you make an example, you have to put enough detail into it that it starts to reveal your assumptions. So now that can start to be picked apart a little bit. The other thing I like about examples is they usually have actors.

‍

[00:33:12] And with that person that's central to the story, I start to build an empathy for them. Okay. And it makes things more memorable. I've read dozens of diversity studies, and I don't remember most of the statistics. If you came up to me and asked, like, why is diversity important, I would give you all the anecdotes and examples that I've heard because that's what sticks with me.

‍

[00:33:34] The personal stories that people tell are what make this a memorable and important topic to me. Not that the data isn't important, but I don't remember it as well.

‍

[00:33:45] As we work on building this shared understanding, we start to evolve based on all these new perspectives coming in. And as we kind of come into an alignment around this, we start to build a shared purpose. And this is a really powerful thing for a team. This is the mission of Test Double. Software is broken.

‍

[00:34:07] We're here to fix it. Now our understanding of this mission continues to change based on new context and new perspectives. And the implementation will change based on what's right for the situation. Sometimes making software better means adding more tests to the project. Sometimes it's building a new tool.

‍

[00:34:27] Sometimes it's giving more talks. Sometimes it's sending an email. I often say I wish the most important thing I did today was commit code. It's usually having a conversation. That's okay. Sometimes it's cranking features so that somebody else can do the fixing. All of this fundamentally works within our mission and helps define who we are.

‍

[00:34:51] I understand why I work at Test Double and what we're trying to accomplish. And with this shared purpose, group decisions start to take on my own individual convictions. If the group decides, hey, we should give more talks at conferences, now I want to give more talks at conferences. I've bought in and I believe.

‍

[00:35:13] As we make continued efforts to get to this shared understanding and have these conversations, we start building connections with each other. An interesting thing happens, it's a positive reinforcement kind of loop. As I make a connection with you, I remember and care more about what you're saying. So, as we continue to make these processes, they reinforce themselves over and over again, and we build a better understanding.

‍

[00:35:39] And as we get better at this, we start to become better storytellers. People who convey information well are storytellers. They can give examples in such a way that they have some empathy with them, and they become memorable. And your story isn't just your team's story anymore, it spreads. It goes to the sales team, it goes to the executive team, now your users are telling the same story.

‍

[00:36:02] And the oral tradition of storytelling to me is pretty amazing. When I think about this guy Homer, who was wandering around, and told the story of the Iliad and the Odyssey well enough, that people repeated it for hundreds of years, until they invented an alphabet, and then they could write it down, and it's still carried all the way forward till now, That's amazing to me, and they, the, these stories really help define what it means to be a Greek person, all through this tradition.

‍

[00:36:34] So, if we start with examples, we can move towards a shared understanding. As our shared understanding continues to evolve, we can get to a shared purpose. Through the practice of continuing to try to build our shared understanding, we build connections, and now we have a shared story that we can tell. And eventually that leads to a culture that's capable of doing great things.

‍

[00:36:58] So, I'm running out of time, but I wanted to leave you with two thoughts. The first, if you get nothing else from this talk, please understand that a shared document does not equal shared understanding.

‍

[00:37:13] And it's good to be able to work together with people. I mean, it feels nice to accomplish something as a team, but to be able to work well together is an amazing thing. I've been part of teams that have had so many different skill sets, perspectives that they could tackle any problem, and it feels great.

‍

[00:37:30] You feel unstoppable. People often ask, like, where do you see yourself in five years? I have no idea. But I know where I want to be when I'm 70. I want to be working as part of an amazing team that's doing great things with people that I really care about. And I want everybody else to have that too. So this is just my perspective.

‍

[00:37:52] I need some diversity of thought around this. So please ask questions now or come find me or email me or Twitter, but I'd love to hear from you. So, thank you so much for your time.

‍