Show notes:

Transcript:

Avdi: Hey, this is Avdi Grimm with WideTeams.com. And Iâ€m talking today with Rob Dempsey of the LifeOfTheFreelancer. Rob?

Rob: Hey, Avdi. Howâ€s it going, man?

Avdi: It’s going great. How are you?

Rob: Good. We overcame the technical difficulties, so we are all about it this morning. Yay Monday! (laughs and woots)

So well, letâ€s just start this conversation off because this will be – at least for the folks at LifeOfTheFreelancer- this will be a bit of a different kind of thing. Not our traditional interview where…we have some definite commonalities in terms of weâ€ve both been doing software, weâ€re both working with distributed teams or another way of putting that is working with other folks self-employed, or otherwise that are all over the damn place. Alright?

Avdi: Right.

Rob: And for me at LifeOfTheFreelancer, itâ€s very important to team up with other freelancers. Huge! Especially nowadays. So youâ€ve been doing that, Iâ€ve been doing that. So we can totally have a conversation around that. So letâ€s start off too…I think by you giving some more of your background.

Avdi: Alright well, so like you said, Iâ€m a software developer. Iâ€ve been doing that for I guess, over ten years. And I started out sort of in the best military industrial complex and I eventually moved into…more into web development. And in the process, Iâ€ve done a lot of working with distributed teams scattered usually across North America.

And at some point, I realized that I really wanted to spend more time at home…as much of my time as I could at home with my family. And so I decided that I wanted to really get good at working with dispersed teams and so sort of enabling that to happen for myself and for more people to be able to choose where they work from independently of who they work for.

And so since –I guess- June, Iâ€ve been interviewing a lot of people who are working on dispersed teams about how they make that work, how they do typically software development. Although Iâ€m going to be talking to some other people that are in different types of organizations about how they manage a dispersed team, what are the challenges and how they overcome those, and the tools they use, and all that kind of thing.

And of course anybody who is listening to this on WideTeams.com knows all these already. But yeah, thatâ€s definitely…I am a freelancer now so Robâ€s thing is all about freelancing. Iâ€ve learned a lot of stuff from his site. And, from your site I should say……and, I have been a freelancer for a while now.

Rob: Yeah, and I was reading your bio. And so again, like you said, you were working in that vast military industrial complex. It sounds like, basically, ‘The Manâ€, right?

((crosstalk))

Rob: I saw the Ratheon cup.

Avdi: Yeah, my military industrial complex mug here.

Rob: You can say Iâ€ve been there and got the mug, right?

Avdi: Yeah.

Rob: So now, when did you go freelance?

Avdi: Letâ€s see, that would be, I think spring of this year? Yeah.

Rob: Right on. So not an enormous amount of time.

Avdi: No.

Rob: But you made that league though.

Avdi: Yep.

Rob: And you have four kids, you said, right?

Avdi: Yep. Mm-hm.

Rob: Right, now did your wife freak out or went out when you were talking about going off on your own?

Avdi: Not really. I mean, she keeps track of the kids in the home and I pretty much figure out how to bring money in and so we keep things pretty well divided that way.

Rob: Thatâ€s good. And did you create a financial safety net having been working full-time for quite a while before you made the jump?

Avdi: I wish I could say yes. The truth is I had been planning on making the jump to freelance at some point, but I had it kind of come to me faster than I had planned.

So basically what happened was I was working for a company called Devver, which the Ruby on Rails programmers that are listening may remember, which was the start-up which was really cool but unfortunately didnâ€t succeed.

So when that went away, that sort of launched me earlier than I had intended into my freelance career rather abruptly. So no, I didnâ€t really have a safety net.

((crosstalk))

Avdi: I mean, I had the best safety net you can get which is just having good friends and knowing people that were able to find…you know, to refer me to work.

Rob: Right on. And thatâ€s a huge point, having that network there. So a few listeners who give a bit of background on me I mean, my background too is software development, even before that IT.

So before I got into Ruby on Rails, blank. I think it was maybe six years ago, now I donâ€t know, I mean I remember messing with Rails before I was 1.0 but I didnâ€t actually start building a business doing Rails development until a little after 1.0 was out.

So my background was IT, I did Microsoft stuff. So I have like that MCSE and I was A+…. So basically,….. And the first time I had my business, I just up and quit my job and Iâ€m like, “I can do it better than this guy” and…he was doing some stuff that I didnâ€t…well he said something that I didnâ€t fully agree with.

And so, I up and quit my job and that didnâ€t turn out so well. So luckily though, the second generation of my business which was doing software development, the way that I set it up was completely to be able to do it literally from anywhere that I was working. And so that I could work with people that were anywhere because I had…well I didnâ€t have a physical location when I was doing IT, I was running around – I was up in DC all the time – so literally driving all over DC, Maryland, and Virginia which will take a minimum of forty five minutes to get literally anywhere.

So yeah, you go to one place, youâ€re up there for an hour or two, you drive forty five minutes to an hour to get to the next place blah, blah, blah basically, half your time is spent just driving around from place to place.  So that really reduces the amount of billable time, so Iâ€m like, alright, I need to do something thatâ€s tech that I donâ€t have to drive anywhere. And so thatâ€s really how I got—well, I ended up doing a computer science degree.

And that actually let me do getting into Ruby on Rails and software development, and agile development which is a…well you know about it, Iâ€m sure your listeners know about it, but itâ€s basically a method well itâ€s principles that manifest themselves as a set of methodologies for developing software that really, it talks about being very customer focused, a lot of communication.

And so when you talk about agile distributed software development or really working with people all over the place regardless, it really comes down to this. Itâ€s really important to focus on the communication aspects of the project.

And so youâ€re talking about, using tools like Skype like weâ€re using, you can have face to face conversations or talk in project management tools, youâ€re talking, even at the development environment itself, really giving you youâ€re feedback and telling you whatâ€s going on….OK does your software suck, are your test breaking? Do you even have test in the first place?

Itâ€s like all this kind of thing and so, when…a lot of the same practices though, whether youâ€re doing software development, whether youâ€re doing really anything where you have people and multiple locations working on the same project, the same principles, the same practices I think, absolutely come into play.

And so Iâ€ve been able to use agile practices on non-software development projects and itâ€s been really wicked cool.

Avdi: Right. Thatâ€s interesting. So agile on things beyond software.

Rob: Yeah, absolutely. And so because again, agile itself is a set of principles that then manifest themselves as different practices whether itâ€s scrum certification and thereâ€s been a whole shitstorm over there and that and that community. Iâ€m glad to kind be away from that. You have scrum or extreme programming, you have all these things but basically we work together for the benefit of the customer.

And so, I remember going to these conferences where people go like, ‘Oh, theyâ€re not sitting side by side, theyâ€re not doing agile and blah blah blah†and Iâ€d like to punch these people in the face. I mean, thatâ€s like, ‘Who are you to tell me Iâ€m not doing agile because Iâ€m not sitting beside the person Iâ€m working with?â€

And I think the future of work further is that we will be…we will have these distributed teams because youâ€re working at your house and Iâ€m working at mine, and the overhead of that is a hell of a lot lower than if we have to come into some office. And whatâ€s the point? I mean, you and I can work together. Where youâ€re up in…where, like Maryland you say?

Avdi: Pennsylvania.

Rob: Yeah, ok. Thatâ€s off completely. So, my fault.

Avdi: Well, not really because Iâ€m really just across the line from Maryland, itâ€s forty five minutes to for me to ride to Baltimore.

Rob: Right on, right? So you can be on in Pennsylvania, and I can be…Iâ€m currently in Minnesota, Iâ€m gonna be at Highland probably in a month. But, you know the point. And Iâ€ve worked with folks in the Philippines, Iâ€ve worked with some of my previous employees in Florida, right? My customers are all over the place, Iâ€m sure yours are too. I remember when I was building Atlantic Dominion Solutions which is my web development business. And I had never met any…a majority of my customers? Iâ€ve never even met them in real life for years.

Avdi: Right.

Avdi: Right.

Rob: So my question to you is what are you doing thatâ€s really helping you to do to make that happen?

Avdi: My biggest project right now  is just the process of sort of trying to bring together the people that are doing this and get the conversation going more because what I found is that…I mean, youâ€re absolutely right, I think this is sort of the trend. Youâ€re seeing more and more of it, especially in web development.

There are some things that you can do that you really require at least part of the team to be on one site. But when it comes to web development, youâ€re absolutely right, you can be anywhere. And there all these groups that are doing it, and theyâ€re using different techniques, theyâ€re using different tools, and Iâ€m trying to sort of assemble that into one place and get people…sort of collect some of that wisdom thatâ€s out there…

Rob: Okay, so for instance, what are you hearing then? When youâ€re out there interviewing people about stuff, what are you hearing that are some of the things that are working pretty well for folks so far?

Avdi: Well, I think the general  experience seems to me that itâ€s not as big a change and itâ€s not as big a problem as a lot of people imagine it‘s going to be. And I think itâ€s interesting you talked about sort of a debate. There is that debate over ‘ can you be doing agile work distributed?â€

But the truth is itâ€s kind of a moot question because itâ€s being done…just like you said. People are doing it everywhere and I hear a lot of things, I hear things like…I mean, obviously communication is key but itâ€s all about sort of the pace of the communication and how you keep it going. I mean, the big thing that I hear a lot is the importance –even if youâ€re gonna be distributed- of meeting up in person from time to time.

I pretty much hear that from everyone. If youâ€re going to work with somebody as a dispersed team, thatâ€s fine. But try to make it happen that If possible, at the beginning of the project, you all get together and just sort of get to know each other a little bit in person. It completely changes the character of every interaction that youâ€ll have after that because youâ€ll have that sense of them in person and so, when they email you or when you talk to them on Campfire or something like that, youâ€re gonna see them as a person seeing it rather than just that jerk in the other end of the internet. And so, thatâ€s something I hear over and over again. Pretty much everyoneâ€s doing some kind of daily meeting usually on Skype or something like that.

I hear a lot about having well-defined expectations. So it doesnâ€t work as well when itâ€s kind of up in the air what to do next on the project…It works better when there is some clear and well defined goals for the iteration or whatever. And I think the thing that the biggest thing that Iâ€ve taken away from everyone Iâ€ve talked to and from my own experience is that working as a dispersed team really requires you to be intentional about it.

I mean, you canâ€t just…I think the people that have the biggest problems or the worst experiences are the ones who just sort of expected it to work, just sort of to happen. And the truth is that as good as the technology gets, everything is still going to be a little bit more of an effort. You and I even had some technical difficulties getting Skype connected this morning. And if youâ€re going to say, ‘Oh, screw it, Iâ€m just not going to do the Skype call this morning.†and youâ€re working as a team, that doesnâ€t work out.

And so, you have to accept the fact that everythingâ€s going to be a little bit more effort than it would be if the other people on your team are sitting across the table from you. And as long as everybody realizes that and is intentional about making it work, it will work.

Rob: Right on, so really what youâ€re talking about then is relationship building between the people within the team. And so less about the project, and more about how do you and I work together to make this thing happen? So youâ€re talking people skills, and not necessarily technology skills at that point.

Avdi: Yeah, yeah itâ€s really just about making an effort, and making sure that the connections happen even if there is a technological barrier, or a time barrier, or whatever it is. Just making sure….itâ€s easier to remember to maintain that communication when you see someone around. But as long as you just make the effort, then itâ€ll happen.

Rob: Right on. Yeah, I mean ‘cause to me, I think as you said, people doing in the software space, agile development distributed is a moot point because it is happening. Iâ€ve seen companies where they have all  their business analysts and all the “businessey” people inside, like internal. But then they completely outsource all the developments.

Where that really falls down is just as you said, no expectations had been discussed. No one even talks about that. Okay, whoâ€s going to do what, what do we expect of you, what do we want to see on both sides? Itâ€s kind of the…not the plan of action per se, but the… what are the rules of engagement, if you will, right? So you donâ€t have that, youâ€re not even laying down the foundation for this whole thing to work.

Avdi: I have a friend, Chris Strum, who talks about working agreements and the importance of working agreements when you have a dispersed team. And thatâ€s basically just having an actual short written list of things like ‘we will report status in a daily meeting every dayâ€, or there are tools that are sort of like internal Twitter for reporting your status to each other and keeping up to date with each other, and working agreement could be, ‘I will update our yammer tool or our presently tool, or whatever youâ€re using at least once an hour†or something like that. Just these working agreements that these groups come up with that help them remember to keep those lines of communication open.

Rob: Yeah, right on. So that forms the kind of foundation, everyone has their expectations. The thing when youâ€re working inside of a company, you have that company culture. Hopefully thereâ€s company culture that kind of dictates how people will be working together. You get maybe that training when you first come into the business. But when weâ€re forming these ad hoc teams out there, … whereas we werenâ€t before….then we have to make sure that we have a basis in place for how we are going to work together.

Avdi: Right.

Rob: Then itâ€s a… I think then the tools and everything else are pretty straightforward. I mean  so to me this stuff seems…maybe because I have been doing it for a number of years.

Avdi: Right.

Rob: Seems pretty straight forward. Itâ€s like, ‘Okay, we got to talk, we got to know what weâ€re doing, and we got to know when weâ€re gonna talk with the customer, whoâ€s gonna say what so we donâ€t step on each otherâ€s toes†and all that kind of thing.

So yeah, that idea of a working agreement is fantastic, just having that right off the bat. You could probably come up with some boiler plate and say look if weâ€re gonna work together, this is how itâ€s gonna be then that is that, because this is what I found to be successful.

Avdi: Yeah, but you got to be flexible too. One of the big insights of agile is that you constantly improve by evaluation pretty frequently, evaluating the things, the tools, and the techniques that youâ€re using. And then you suggest improvements, and then you test, you see if the improvements have helped. And I think thatâ€s another thing thatâ€s really important especially for dispersed teams. Because dispersed teams really are more reliant on tools and practices to keep those lines of communication open.

You really have to have retrospectives or something like retrospectives every couple of weeks, or at the most, every month in your project and just talk about whatâ€s working and what the annoyances are and then possibly come up with…so you may add a new working agreement, or you might modify one or you might decide, ‘weâ€re gonna try a different tool for our meetings†or something like that. You really have to keep stay flexible on that and stay on top of that stuff. If somethingâ€s not working right, you canâ€t just let it fester.

Rob: Yeah, absolutely. So for anyone in the non-software listening to this, a retrospective is where…like Avdi and I will sit down and say like, ‘okay, how are things going? Whatâ€s been working well? Whatâ€s not working well?†So taking those “whatâ€s not working so well” and then figuring out how do you make that better. And then implementing that like say, over the next two weeks or a month but personally, I think one month is too long for anything. Iâ€m on internet time here buddy. So every two weeks you say ok well letâ€s try this out for about a week or two, see how it goes on the project, and then if we need to change yet again, then we change yet again. So yes, always trying to optimize your process whether thatâ€s how youâ€re developing software, how youâ€re designing something, how youâ€re communicating internally. You got to look if what the hell youâ€re doing isnâ€t working. And if itâ€s not, then freaking change that stuff right away. Because Iâ€ve seen project get derailed extremely quickly because basically no one does address the issues. So you got to address the issues.