Lessons

Lesson Info

Communicating with Developers

We're gonna talk about communication. We're gonna talk about developing a common language and finally we're going to talk about this idea of code literacy. The first step of communicating. Again, Scrum, Andy mentioned this yesterday. I really dig this drawing, not because, just because of the pretty colors, although the colors are pretty, but because it's the most accurate way of actually ever seeing this described, like I have tried to draw this myself like... Parallel means everybody the same time but we don't all really start at exactly the same moment, and then we all don't always finish at exactly the same time. So, I really like this idea that we all start on a staggered format but for the majority of the process, we are working side by side. So, whenever we show you a list of tasks, that means we might have started them then, but there comes a point when they're all happening at the same time, and we gotta maintain communication across those channels to make sure that we don't g...

et out of sync. Well, we're gonna add to this, these are all the ceremonies that Andy reviewed yesterday. Again these are daily/weekly processes, but we're gonna talk about the in between spaces, things that are always open. So, first up, my favorite, sort of where I think the people that I work with, where I think we really kicked up our production level was maintaining Google Docs around specific parts of our process. The way that this works with my development partner, we meet every morning and we have something that we call 'work week' and it has all seven days laid out within a Google Doc as header elements, and then there's bulleted lists of tasks. We walk through and make actionable the next thing for every project in the queue. It's not a long process. The idea's to think quickly, very similar to Scrum, and the main goal here is to both contribute to the process of what is the next actionable thing. There's a great book "Getting Things Done" where he talks about this like, there's an idea that David Allen Green, I think, author, David Allen, take this abstract idea, the user story, and that's gonna cause both the developer and the designer stress unless they know what they can actually do about it. So, by whittling it down to an actionable step does this thing cognitively, it actually strips away these open loops, these stresses, and lets me know: this is the next thing I need to do. So, it focuses the team. But the idea that these documents are open all the time, it's different than a chatroom, because it's a collection, it's a list, this is our... An example of this our content inventory, our plain text files, our component inventories, these are all collaborative documents that we're communicating and contributing to and everybody is a part of. Next up is channels, sort of a generic term. It means chat applications. I think, they're trying to get away from trying to call them 'chat' because they're sort of like trying to blend the business model of what it actually does. So, Slack, which most of you may have probably heard of, and HipChat, we use HipChat at Exegy. I was actually going to call the team up but then Andy and I talked about the... So, I could if I wanted to, if you guys challenged me. They're always open and the cool thing about them is you have access to people, but these are, it's different than a task you assign somebody, the way that channels work when you work with teams, again, these are rules that I've learned with experience is that there are, they come with some general etiquette. It's learning to respect each other's space, so, you wanna be respectful of your team members' time. So, everybody's opting into this practice, right, we're all gonna be in HipChat, we're all gonna be in Slack, but you gotta understand that people have families, like the whole idea of distributive working, and working with everyone, it's cool, right? But there's just some unsaid rules that if, and I understand when people break them 'cause you're in and out of timelines and stuff, but these are just things you should keep in the forefront of your mind if you're trying to sort of play nice with others, so, be respectful of each other's time. Where as Scrums have a designated start time for the whole team, responses in these channels, they're not guaranteed, and the best way to pay it forward is to like, is to answer people, like the way that we use it in our team is people will throw out global questions, and that's sort of like your opportunity to pay it forward and go, "Let me answer this global question for somebody who's struggling with this design concept," and then I'll answer it, and then other times you'll get personal messages directly to you, and again, it's up to you when you answer it. And, so, there's no right or wrong answer, but the effort that you make in answering these responses is a fair way to look at what to expect from other people, you know, so, understand that you're dropping the flag, you're saying, "I need some help," but there's no guarantee that anybody's gonna come and pick up that flag, or answer that call right away, so, again, as great as they are, understand that your friends and your collaborators are not robots, they have to sleep and all of that stuff, social lives... Just to add a little something, so, at Favorite Medium we've kind of also very much believe in channels, we use Google Hangouts for pretty much all of our communications, not only the Docs, but also Hangouts to communicate. Couple of key things that I think made things a lot easier: one is having Google Hangouts, the app, on your phone, just makes it really easy to kind of stay connected because you're often on the go. The other thing is that download the Hangout extension, you know, say, for Chrome, it's a much better experience than trying to constantly trying to go through Google Plus to kind of figure out where the Hangout is. Just makes it so much simpler, and what's really interesting about the way you communicate is that as you kind of look at the process in which you communicate it also defines the culture of your company, right. So, process and culture inform each other, and that's something that's really important. You'll notice that if you're working with a client, you know, you're kind of seeing a different agency, and you can feel that tension, that tension bubbles up, as part of the culture, but if you look kind of underneath, a lot of it is about the process. You know, what are the things that people are frustrated with that essentially inform that culture. So, there is that kind of back and forth, a little between, but it's really important just to kind of stay connected and keep that collaboration going and for a remote team, it's, you know, very critical because we have overlap when we're on certain timezones, and then a lot of times, you just have to let that team run a little bit. So, very critical, and I think that you're going to find it so helpful just to be connected all the time. Yeah, and then you're gonna find the software that works for your team, I think, I have all three. Like I have Skype, Slack, and HipChat, and different teams prefer different ones. So, I just adapt and sort of just move around. And the other thing that we do, too, when we're talking about kind of respecting time, because things blend, is, you know, in our calendars we actually block out, you know, like I have blocks for family time, right, like because it's not... The traditional workday now breaks down when you potentially have team members in different locations, so, one of the key ways that you can kind of start to establish that respect is by having and just blocking out, "This is my time, this is work time, even like, I don't even want meetings here," and just starting to look at your calendar as not just the place for profession time, and not just the place for when meetings happen, but to kind of dictate, you know, the way you wanna structure your time, and it's not perfect, so, sometimes there might need to be a meeting that overlaps into one of those areas, but at least there's kind of an understand and it would be more of like, "Hey, can we do this during your time? I realize this is your personal time." Changes the conversation a little bit and again creates that respect within that culture. Yeah, cool. Yeah, we are all real people. The other method, format of communication are these Hack Sessions, so, within chat and channels you can ask discreet questions, you can get sort of maybe codes that fits your things, your solutions, you can send JPEGS or references to files back and forth, but like we said before, yesterday, sometimes there are these micro-tasks that sort of add up, or you have a bunch of cards in the queue relating to a specific user story and sometimes there's (stammers) again, as much as distributive development as "Yay, good." Nothing beats a concentrated, side-by-side, at-the-same-time, synchronous, collaboration where you're actually asking/answering questions, filling in for each others. So, again Hack Sessions, most literally comes from again, programmers did this, they found that this pushed things forward. More and more I see designers doing this without developers. Just sort of hack on a project. It's a concentrated period of time, a hack, a concentrated period of time that everyone agrees: "We're not gonna do anything else but this." You're shutting off e-mail, you're shutting off all this other stuff and for two hours, you're just gonna geek out, zone out, answer questions, around this particular piece of functionality. And again it goes, this is the most literal translation of the parallel design/development idea. I have designers sit with me as having more front end knowledge than them, and I dive into the code, and then they ask for things to change, and I'm not just doing what they say, I'm teaching them how to do what I do. Like this is where the knowledge exchange happens. Like they're curious of the difference between CSS and Sass. So, Sass is a pre-processor for CSS, which allows me to abbreviate and condense some of my statements. So, designers are curious 'cause most of them understand basic principles of CSS, but they wanna know how Sass works, and I'll show them and it'll set off like, they'll start to think and design differently. So, they'll go, "Oh, you can do that? Well, why don't you do this?" Again, I've been looking at it for so long as a developer, when I'm in that mindset, I'm not making some of the associative leaps that a designer's making. So, I need them to leap for me while I'm thinking very technical, and problem solve. So, it's basically having both sides of the hemisphere of a brain working at the same time, and that Guillermo del Toro movie calls it 'drifting,' right, so, it's like this idea that they have two pilots of these giant robots and so it requires both sides of the brain to be working at the same time. (Andy whispering) Yeah, Pacific Rim, yeah, yeah. (laughing) Is that where you went? That's where I went, just there. I wrote a blog about that, we'll put it in the show. So, the rules here are, this is the team at Exegy working on a concentrated sort of format around a goal, so, what we're doing here is we're asking questions, I encourage you to just submit when you don't know what you're talking about, you know. And also, encourage the developer to have you articulate yourself if you use a design term that they might not understand, and again, realize that this is where you're doing that translation of concepts, you're teaching each other each other's languages. And again, stand up for your design goals, as much as you like, say, "I don't understand what Sass is. I don't understand the difference between Rails and PHP. Can you explain it to me?" When you say something like, "I need to create a hero unit that sort of like impacts and gives an immersive experience, and sort of drives the eye through my vertical rhythm." They're gonna wanna ask you to describe exactly what you're talking about, right? And stand up for that stuff. You know, like don't feel like you have to reduce the importance of your design goals, because it doesn't translate immediately, 'cause, trust me, developers want to know, they want to know, because they want to learn to anticipate your needs so they can be better developers. So, at the same time as you're asking questions, stand up and sort of like speak, speak the word when it comes to design language. The other side of these sessions is... I guess every team's different, but I've always known white boarding is more of a design exercise. I know developers do white board exercises as well, what I'm encouraging here are these cross discipline... I'm saying invite developers to design white boarding sessions, right, because the realm of these ideas, these realm of the goals, this is a universal space, because there's no aesthetic here and because you're in thinking space. So, again, developers want to learn your language, and this is a place, again, you're not in code land, you're in this active wire framing block modeling land, it's a really powerful place for potential for sort of like learning from each other. Developers again are really interested in the user story, they want to know the why, they do want to know that last part of the, like, they wanna know why, because, the how, they get the how, but knowing the why, and having that consistent reminder of where in the big pictures this fits, it makes it more than just the tasks. "Okay, gotta make this, me typing again, I gotta make the button red because they said so." It's because it performs a certain function within a larger user story. And also, developers are gonna make some design suggestions. They're gonna say,"'Why isn't that round?" They're gonna say "Why is it that color?" You just need to be open to this, they're acting, they're reacting instinctively, so, again, I encourage you to not, as much as, if you expect to be let into code land you need to let developers into design land. You need to let them, like Andy did yesterday during the sort of user story, like, keep at: "What do you mean by that, what is sort of the larger goal?" It's sort of like, again, get away from features, and get into stories, and try to find out what is the actual user benefit that they're suggesting and sort of work it that way, rather than taking it as maybe as an aesthetic critique, like, "I think the font's too small. Why?"