The Ruby Freelancers Show 043 – Improving Teams

Podcast: | (Duration: 52:32 — 48.1MB)

Panel

• Eric Davis (  )
• Jim Gay (  )
• Charles Max Wood (   )

Discussion

01:39 – Addressing Team Issues

• Implementing Change
• Stand-Up Meetings

04:44 – Stand-Up Meeting Issues

07:37 – Organization Politics

• Expetise
• Experience

11:21 – Idea Resistence

• People Problems
• Control

18:16 – Problematic Coworkers

20:26 – Team Communication

28:10 – Assigning Tickets & Stories

36:22 – Finding Solutions to Problems You Don’t Understand

38:04 – When Change Doesn’t Happen

• Satisfaction Level

40:01 – Management Issues/Changes

42:43 – Team Planning

• Planning Poker
• Estimations

48:17 – Ideas for Integration

• Leveraging Experience

Picks

• (Jim)
• (Eric)
• (Chuck)

Transcript

ERIC: Helloooooooo!

[Are you a busy Ruby developer who wants to take their freelance business to the next level? Interested in working smarter not harder? Then check out the upcoming book “Next Level Freelancing - Developer Edition Practical Steps to Work Less, Travel and Make More Money”. It includes interviews and case studies with successful freelancers, who have made a killing by expanding their consultancy, develop passive income through informational products, build successful SaaS products, and become rockstar consultants making a minimum of $200/hour. There are all kinds of practical steps on getting started and if you sign up now, you’ll get 50% off when it’s released. You can find it at nextlevelfreelancing.com]

[Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net]

CHUCK: Hey everybody and welcome to Episode 43 of the Ruby Freelancer Show! This week on our panel, we have Eric Davis.

ERIC: Hello!

CHUCK: We also have Jim Gay.

JIM: I’m back!

CHUCK: You are back! We missed you!

JIM: Thank you.

CHUCK: I’m Charles Max Wood from devchat.tv and I’ve been working hard on railsrampup.com. So if you wanna learn Ruby on Rails, go check it out!

Alright, this week we’re going to be talking about — I don’t know what the title of the show would be yet, but we’re going to be talking about like improving team, processes, communication, etcetera, etcetera. When you’re a freelancer on the team and — we may go into like what you can do when you’re new, what you can do when you’ve been around and earn some street cred, but let’s just jump in and talk about some of the stuff. Just to kick it off, I generally like to just come up with something that’s relevant from my experience. I’m working on a team right now, and the things that actually been reasonably good over there. And most of the time if I have a concern, or a thought, or an idea, I can just get away with going to the Director over the project and he’ll usually talk through it with me and then implement a change if it’s good idea. So, I just kind of wanna throw that out there because sometimes the solution is pretty simple.

JIM: Yeah! I’ve definitely done that; making sure that I’m constantly talking to whoever the project manager is. I don’t know, I’ve kind of looked at conversations like around process and comments and say “You know, I’ve noticed this and I wonder about changing it to that”. Just in terms of thinking like “let’s try it!” or maybe “we should try it!”. Or if you don’t wanna try it, fine. I’m sure there will have other things. But I’ve never felt like even though sometimes I felt really strongly, we really ought to find a better way to communicate or something like that. I never tried to put my foot down like “look, it must be done this way”. And sometimes I feel like I want to be the guy who will do that, because I wonder for the goal faster or improve it. But I’m often trying to work with them, trying to figure out the best thing for the team.

CHUCK: Yeah, that makes sense. How do you decide that something is worth to doing with the team? Because most of these teams are different, and so what works for the team that you’re working with isn’t necessarily a good idea for the team I’m working with?

JIM: For me, I try to get “immediate win” so like if I noticed something about the process from neither project to another something about the process that’s not helping. For example, I know a lot of organizations will do like a stand-up meeting; and they might even say “you know, we’re not really doing scrum” or “we’re kind of agile”, and their stand-up meeting consists of standing up and chatting for like up to 45-minutes about what they’re doing. And so one of the things that I often find is either introducing a very quick stand-up meeting or non-existed, or saying why don’t we just (if there’s tangential conversation) say ‘hey, if you two people need to talk about this, talk about this afterwards so we could get through this’. And right after that, it’s immediate win because we’re not spending 30-minutes standing around, chatting about things where half of the group is like looking away trying to — they’re picking up their phone and looking on Twitter or something like that while they’re waiting for the conversation, they don’t care about, to finish.

CHUCK: Yeah. I’ve been in those stand-up meetings where you start out sitting down because you know it’s going to be longer than 10-minutes.

JIM: [laughs] Exactly.

CHUCK: Yeah, that’s definitely a win. I can’t say I’ve seen that issue in particular in where I’m at. I mean, usually somebody else on the team is also “keeny” or aware of the fact that are stand-up meetings are going too long. And so we’ll have an agile retrospective and when we talk through it, we’re like “yeah, this stand-ups are taking too long, what do we need to change?”, which I guess is another solution. But it’s really interesting to me, and I’m not very good at this by the way, I have almost as much tact as — well, I don’t have any tact. So when I bring up a problem, I generally just say what it isn- and that usually gets me into trouble. So let’s go with the hypothetical here and say that you are working
with the team whose stand-up meetings take too long, how do you address that with the team?

ERIC: You start bringing cherries to the meeting..

[laughter]

CHUCK: That’s the tongue-in-cheek way of doing that. I think it might work for some teams – sit down for the stand-up. Wait a minute!

JIM: The way I’ve done it in the past is two ways. It depends on whether or not they’re doing a retrospective and they actually wanna improve on their process and change overtime. [inaudible] like we talked about a minute ago, go to the project manager and bring it up and say “Look, this can be much faster. I don’t need to hear the back and forth on this particular topic. I just tend to know if I’m blocking anything on it or stating it an input for me”. And that I think, usually helps. But then the retrospective can often turn into like if you’re not doing it right, can kind of turn to just a bitch session like everybody gets their say to complain about something which can be really bad. But if you have the right perspective, you talk about what didn’t go well or what did go well and try to figure out ways that you can improve upon it. And then you actually try to improve on it and change the way you behave the next iteration.

CHUCK: Yeah the way that the guy that our project manager I guess do would call him when we do our agile retrospectives – which we haven’t actually done for awhile. Anyway, he gets up and he says what’s good, what’s bad, and what’s ugly. And good is good, bad is bad, and ugly is “we never wanna see this again”, and so then we talk about some of those things. I think that is somewhat useful; it just depends on the situation you’re in. So, I mean sometimes some of the stuff that gets brought up is as bad or ugly as kind of silly, but at the same time I mean you just deal with that. And again, I have no tact so generally I just — my tact is I keep my mouth shut instead of going [expression], that’s dumb.

ERIC: Yeah or the “tsk tsk tsk”

CHUCK: Yeah

ERIC: Yeah I mean it all comes back to like politics and stuff – not government politics, but kind of organization politics. Like for example, if you’re the new guy you have no political capital. So even if you have a good idea and a good change, that’s going to be a guaranteed win. You might not have enough capital there – it actually push it through and make it go through. And so kind of what I’ve done is, I’ve actually started to kind of make a list of “here’s the things that I would change” and “here’s the things that might be a good idea to change and why”. And overtime, as you get more experience with that team and you get more political capital, kind of go through that list and bring up things that are going to be the best win for what you can push through. Unlike switching from like our spec to test unit or something might not be that usable win and it might cost a lot so you might never ever get to do that, but kind of in a stand-up meeting to — two-minutes per person, no other people talking, that might be an easy change to get through.

CHUCK: Yeah. One other thing that worked out for me in the past was when I worked at public Engine. So I was a full-time employee there I wasn’t a freelancer, I wasn’t consulting or contracting with them, but I got in there within the first week. I looked at them and said “You know we really ought to do — we really ought to do this and that”. And most of it was like we need to set up and continue with this integration machine and we need to be looking into implementing these kinds of practices because we have these kinds of problems. And it worked out well because for one, my boss was really open to that kind of thing. And the CI thing in particular was something that he’d actually been considering and some of the other team members had mentioned to him. And so the fact that I had experience setting one up paid off in that way as well when I basically volunteered to bring it forward. So if it’s something like that where you can actually just jump in and more or less provided, then that doesn’t really impact anyone else since those are easy changes to push through. And the other is, if you can talk to whoever does call the shots and kind of gain them as an advocate one way or the other, it helps out, too. Because then it’s not just you, it’s them pushing the idea forward and saying Chuck or Jim or Eric or whoever, whoever it is, whoever you are, they can say “he has experience with this and so he’s going to help us make the transition”.

ERIC: Well it also depends kind of with the role you’re filling on the team. Like if you’re brought in just to be an extra developer and sit in, you’re not going to make a lot of change. But if you’re bright in as “You know, Jim here is an expert in XYZ and Jim proposes something about XYZ”, there’s going to be a bigger chance that that idea’s going to be pushed through. And so that’s a big factor, too. And that’s kind of either get it as “how much of a deposit of your political capital do you get just based on the role that you’re coming in as”.

JIM: That’s a really good point, plus that and your experienced. The expert’s experience in that particular thing might make that change go a lot faster than if the team, without the expert decided, just try and do that.

CHUCK: Yeah. And the point that I was trying to make earlier was that sometimes you can point out “You hired me to be a developer, but I’m also an expert in this and so I can help you get here”. And sometimes that’s enough for them to be confident enough to move forward with it.

ERIC: It’s good point.

CHUCK: So what if the powers that be, the project manager or whatever, is resistant to the change that you wanna make but you know would payoff in a big way?

JIM: I think it depends on the change. If it’s kind of individual develop or productivity type thing, you might be able to get a way with just doing the cost or style. Like say if they don’t wanna do the CI Server, well okay maybe you, as a freelancer, can set-up your own CI Server to do all the benefits and at least give yourself the benefits. If it’s like a bigger change like change in meetings or larger processes, you’ve kind of can’t do that. Unless it’s like you can just have commits all the developers that, “hey, we’re going to have our own stand-up and keep it really short,” type thing.

ERIC: Yeah, I definitely agree with that. Like if there’s some particular pain point, I would rather try to bring it up in conversation and continue to remind people about that pain point even though where. If we don’t make the change that I think or fully expressed would do away with that pain, then I would just kind of keep talking about it. If for example you don’t have CI, very commonly you might pull somebody else as code-in and it breaks something that you were working on. Or somehow, something goes out to production and people, they don’t realize that some features that was released 3 weeks ago is not broken because there was nothing, no test recovering it or something like that. Those are easy ways to point out that like “look we really all that big, tracking our writing test and have it continue as integration server”. And all the better if you can set it up yourself like that and show them “Look! Now, even the non-technical people can see: is our bill green? Or is it red? What is our test coverage percentage?”. I think giving the non-tech people involved in the project some insights into what’s happening can really be a good thing. I mean sometimes it’s dangerous, depending upon what information they have and what per person is like. But if they can at least see what you’re doing and get a feel for progress or how things are moving on, I think that’s better – more of spread out communication.  One thing in particular is like — I’m on a project where they have exception notifier in a couple of the apps and it’s sends out an email about exceptions; and that email only goes right now to one person’s. So he’s kind of gotten into habit of ignoring certain exceptions and then he knows which ones are really important and — but the rest of the team has no idea. And so one of the things that we’re going to try and move to is some better view like a air break or airbit self-hosted exceptional gauge where we can actually see a list of what has happened. I just kind spread the knowledge about what’s going on with the app. It’s valuable.

CHUCK: Yeah that’s an interesting situation, too. Because sometimes you — what we’re talking about here is “people problems”. And sometimes, the people problems are “Oh yeah. I didn’t realize that there was a way to make sure that everybody knew about the exceptions” or “we just didn’t have time”, or whatever the situation is. Sometimes it’s just — it just never makes it as a priority and that’s understandable. But at the same time, sometimes there’s that guy that just — he’s real worried that he’s going to lose some kind of “political-power-capital” or whatever by giving up control of the tool. And I’m trying — I’m deliberately looking for these areas that are hard to deal with, and see if we can come up with this as far as “ways” to deal with that.

JIM: Yeah, that’s a tough one! Because that’s — I don’t know how common it is, but I’ve definitely run until situations where it seems that somebody wants to hold on to that power over certain aspects because — I don’t know, they just feel that that’s theirs — so were, I don’t know I guess like what I really wanna pontificate about why people do that, but people definitely do that. I don’t know! Determining like — probably just asking questions is the approach that I would take. If someone is in-charge of knowing more about the exceptions, well I might as well ask regularly to find out as much details as possible and kind of be as annoying as possible until they are so irritated that they “Fine! I’ll add you to the list” And then once you are on that email list for the notifications you can say to like a project manager “Hey! It’d probably be good for you to see what’s going on with our exceptions. Maybe we could put it in a place where everybody can see it”. And I think kind of a — I can’t think of the same, like sunlight being a cure for anything — but just “shedding more light” on the situation can be helpful.

CHUCK: Yeah. One other way that I’ve seen something like that handled is basically — you kind of wind up going above their heads, but you don’t treat it that way. So basically the idea is, as you go to whoever’s higher up and you let them know “Hey, look! This is the situation. We have this tool; we think everybody should have access to it. It looks like somebody is a little bit possessive of it. I don’t really wanna cause a problem there, is there any way that we can get access to that?” And then, let them know that we’re going to treat them like the expert. So instead of taking the power away, what you’re saying is as “Hey, this is the tool that now everybody’s going to have access to” and we’re going to empower that guy, anyway. In that way he’s not losing whatever he’s afraid of losing, and instead is being encouraged to be an asset to the team.

ERIC: Yeah I think that’s a great, great approach. I mean I never mind whenever you have any team members, if they’re not performing the way you want them to, you do your best to put them in the position to perform really well. It’s not like “Oh, this guy’s being a pain! Let’s get rid of him, I’m so tired of him!” It’s so much better for everybody to have that developer do better. So yeah, I totally agree. Help them to feel like they have ownership and that the rest of the team relies on them, but we just happen to need more information.

CHUCK: Yeah. I do wanna point out though that there are — I’ve been on teams where there people, usually just one maybe two out of the entire team, that really no matter what you do, they’re just going to be a problem. It’s usually not your call to get rid of them, but you can definitely encourage somebody to take action. And a lot of times if you wind up being in their cheering corner, even though there’s nothing you can do to make them productive — in fact there’s nothing anyone can do to make them productive. The fact that you keep pushing and trying to find ways to help them, contribute the way that they need to, is enough to highlight the fact that no matter what is going on, no matter what anybody does to try and help them out, you’re not going to be any help. And then the powers like that be, the manager whoever, then can make that decision and say “Okay well, we’ve done everything we can think of”. So unless you wanna change, you’re probably going to wind up leaving.

ERIC: Yeah. I was on a project tour that was exactly the case. We had a developer who just wasn’t productive and would kind of put up a brick wall every time you challenge him on the things that he was doing. And we would say “Alright, well let’s try him out on this aspect of the system” or “Let’s try him out on this one”. We kind of bumped him around to different tasks until finally; we’re out there with Sandon. It wasn’t my call, but the manager said “I think it’s time” and unfortunately that’s the case. But my perspective is always do, even when things look like they’re bad, especially initially like when you first decide like this person is causing problems, you should try to fix these problems, figure out how to make things better, how to more communication and more one-on-one meetings with his or her manager, to make sure that behavior changes. But obviously that worst case scenario is letting somebody go, but kind of veering off of a processes, I think.

CHUCK: Yeah, I think so, too. So one other thing I remember when I was working at one of the places, I  think it was when I was at PMA Media Group, was that we all (we all had different musical preferences) and so we’d all put our head phones and just code [laughs] and we wouldn’t talk.

[laughter]

JIM: That can be good. I mean it’s not like every team has to always talk all the time, and we certainly getting in the zone and writing code by yourself is good, and pairing is really good. And I think there are different people respond to different things. Recently, I was in the office with handful of people and we used — I can’t remember… turntable.fm or something like that. Some website where you could all select — like you could be the DJ and it just will go round robin to each person and play in their playlist and — it was awful [laughs]. I liked maybe 1/3 of the songs that were there and the rest of the time I was just like thinking about a song and how I did not want to listen to it instead of focusing on my code with it as a background sound.

CHUCK: Yeah, that’s true. I think the problem that we had is we didn’t implement another good way of communicating so somebody had a problem with question. It was like this major interruption.

JIM: Yeah! You know a chat room, I found to be really valuable. Like individual chat is fine, an email is fine, and cover views on portal quests some things like that are great, but a chat room just throw any kind of conversation in. I think it’s fantastic because I hate when I see somebody working hard and they have their headphones on and they’re head down. And I might have a question; I’d rather just toss my question out there and hope that somebody can answer rather than trying to tap that person on the shoulder and interrupting them.

CHUCK: Yeah. The team that I’m working with right now uses Skype. When I worked at Mozy, I ran their tech support team, they had an IRC Server in-house. And that’s what we use there. And there’s definitely a lot of power to that because, yeah, if you anything, any kind of question or whatever, you can put that out there. And the other nice thing was that in a lot of cases when I was interfacing with the engineering team, if didn’t know who to ask the question of which happen less unless frequently the longer I was there, but what would happen is I’d ask my question and then whoever happen to see that I had said something in the channel would then poke the right person. So they’d say their name and then ask a question or say their name and indicate that I’d asked question. And so it was really easy to not just figure out what the answer was, but figure out who had the answer.

JIM: That’s a good way of, like you said, if you don’t know who to ask – just an open chat room is a great way to just have it answered. But another thing that I liked about is I could go to you Chuck and say “how do I do this with this part of the system”, and if Eric has never touched it, if we’re talking individually either via a chat or email or something individual chat, he may never learn about it but not seeing that conversation happen in the problem. So developer chat or group chat is always, I think, a great way to make sure that the people who aren’t totally focused on this particular features that you’re talking about are at least exposed to conversation around them.

CHUCK: You just have to make sure that you have a “bot” in there that can tell Chuck Norris jokes.

JIM: [laughs] Exactly. And post mean pictures from the web.

CHUCK: Yeah.

JIM: I worked on a project where we were setting up a Hubot inside of Campfire and we, for some reason, everything like that worked. But any time we try to get it hooked up to pivotal tracker or anything useful, it wouldn’t work; it would like crash.

[laughter]

JIM: So we’re going to have to tell jokes all day long, but then like the actual productivity didn’t seem to come out of the thing.

CHUCK: That’s funny.

“Hubot, what’s the status on ticket number 19349?” “Did you want this picture of a cat? I can haz cheeseburger?”

[laughter]

JIM: I think my favorite thing on that project, to us — we we’re trolling somebody else in the room. And every time he said something, like he would often tell one joke or request an image of a particular thing, we had it specifically return something else. So he was always like “why is this not working anymore?” That’s more of a distraction, that doesn’t really help our process [laughs].

CHUCK: Yeah. Our IRC bought it Mozy responded to Chuck Norris jokes. The funny thing was, was that my handle was Chuck, and the trigger word for the Chuck Norris jokes was Chuck! And so whenever somebody was trying to talk to me, they get a response from me and a response from the bot.

JIM: [laughs] Nice.

CHUCK: But anyway, that’s neither here nor there. One other thing that we views a lot with the client that I’m working on since a lot of us are remote is — we used go to meeting in Skype. When we were in Paris, a lot of times we’re on Skype and then when we have our meetings, together we get on go to meeting. And it’s nice to be able to see other faces, which is something that go to meeting provides up to 6 faces. We have more, usually more people and seats than that, but the first 6 people get on and you can see them moving around and talking. And the other thing that’s nice about that is that, you have to hide bandwidth of voice communication because sometimes I can communicate well by typing, but sometimes it’s much easier for me to kind of fumble through the idea verbally and you kind of get my thought process as part of the next.

JIM: Yeah definitely. It’s a lot faster. I’m on a project now where we’re using Adobe Connect. It’s the first time I’ve ever used it to name and know it existed. And you can actually have, I think, up to 22 people in the video, so that’s pretty cool. But it is flash-based – just not cool.

CHUCK: Now it’s Adobe..

[Jim laughs]

CHUCK: I’m kind of curious to see what — if Eric has a meeting to add on that as far as getting people to talk or chat or communicate that way?

ERIC: I mean for me, having just during the Skype Voice Chat or even just picking up the actual phone and calling works for the most time. We tried Skype Screenshare here and there but found there’s too much slag and just stuff redrawing took too long, so we actually found Google Hangouts to be really good. I’d set up so one monitor would be my code that’d be sharing that and then my other monitor would be my pair’s code. And so basically we’d hitted the same thing on his and by reverse, and so we could actually see what they’re doing and then what we’re doing and just be able to watch a pile that kind of different launders. And it was a lot faster than have a lot of redraw issues that Skype did. I mean that was actually really good because we were doing some performance tune-in and have a new relicope, and then one screen while the other person’s tweaking stuff like — was really nice.

CHUCK: Yeah, that makes a lot of sense. It sounds like a perfect idea, too. We’ve done some screen sharing, and yeah, the Skype thing didn’t really work out. So I have to look at some other there.

ERIC: I tried doing remote pairing with a shared screen sessions, but I’ve never quite made it a part of my workflow. So one of the things I’m interested in doing in the future is learning a little bit about screen or Tmux. And I hear great things about the Prag Prog Tmux book, so that’s probably something that I’m going to be picking up to…

CHUCK: Yeah, we’re using Tmux and then Emacs and that seems to work pretty well.

JIM: So I’m curious because I’ve ran into this a couple of times, what your experience is. But, having tickets of stories or whatever you want to call them, assigned to you rather than the team, the developers, come in together and choosing on their own. So we’re working on something and I, as the manager, think “Okay well, I’m just going to give these 3 tickets to Chuck because he’s worked on that before. And Eric, you can take these 4 because you know about this aspect of it”. Have you ran into that and what’s your feeling on that?

ERIC: If the manager knows, like “Eric’s done the back-end stuff and Chuck’s done the JQuery stuff, then that could work. But for the most part, every time I’ve ever have that the manager said “Hey, I’ve given you this. Are you the best one or should I give to someone else?” And so there’s kind of like a second review of it to see who she get it and who’s best for it and also based on how much time every one has. I think it’s kind of get to kind of get have the developer sign up for something and make the commitment themselves like “I’m going to work on this issue”. Problem you just have to watch for is some people tend to over commit and take everything and then they don’t get anything done. But you can spot that pretty quickly.

CHUCK: Yeah. I’ve only worked on teams where the assignments were done by the team sitting down and somebody go ahead “I’ll take that”. On rare occasion, I’ve seen it go the other way and I’ve had it go the other way for me where somebody said “I really do know you’re the right person for this. Please take it”. But generally, the other approach is what’s worked for the team so I’ve worked on — and then the other can be the exception when there’s something has to be done a certain way and they know that you’re the person that can do it.

JIM: Yeah. I’ve definitely had those situations. I’ve find that I’ve, at least most recently, found that just assignments being done by some management team or product owner or something like that, and maybe with a little bit of a discussion from the team. But I always, like your experience Chuck, I always find that it works a lot better when the developers actually sit down and without interference from people who are not going to be doing the development, they choose how to do it. That’s tough, though. If the team doesn’t do it already like that and how do you convince them that “now you have to let us figure it out for ourselves”. That might be kind of hard for a manager as well like “no, I wanna see who is assigned to this, I need to know”

ERIC: Ah, that’s kind of tough.

CHUCK: So the thing that comes to mind for me, and this is something that I’ve seen in some of the teams that I’ve worked on, it’s that in some cases, there’s a hard deadline for a feature. So let’s say that they need feature X and they need it by next week, okay? So next Friday, it’s gotta be done; so that gives us one week to get it done. Well that automatically disqualifies half the team from doing that feature because there’s this time constraint on it. And so when you’re sitting down and picking tasks, a lot of times the team will look at…somebody else say “well I do that” and then look at him and say “No, you can’t because it won’t get done on time if it’s you. And that says nothing about your skill level; it’s just that you’re not familiar with that part of the code and we need somebody who’s been in there for the last two weeks”.

ERIC: Sure!

CHUCK: And so you make allowances for that. The other thing that happens is that — and the reason that I like allowing teams to pick tasks is that, a lot of times there are…I would dare say most of the time, half the stuff in the back are I guess stuff that nobody has done before. And not only has nobody done before, but it really doesn’t make a ton of difference which section of the code you’ve been working in or most familiar with because it’s totally new. And under those circumstances, I like having the team being able to select because some of the guys on the team, and I’m one of these guys, all go in or all pick the one that I think is the most interesting which usually winds up being one of the harder ones to do. And it’s like “Okay well, that looks like a really interesting challenge and it gives me a week or two to work on it”. And so then the other guys that are more interested in “Hey, you know I just want a couple that I can just bang out; I get them done, I get a pat on the back, I get my ‘attaboy’ and then I can go and help somebody else with something else if there’s time”. They can pick up those kinds of task. And so you kind of get the best of both worlds with that and then, like I said before, you allow the product owner to put constraints upon the stories so that it meets their needs and it gets done in the time that they need it done, but doesn’t restrict the team as far as how they handle it.

JIM: Yeah I think the danger, at least when I think about having things pre-assign, I think the danger there is that like “I may get my tickets and you get your tickets and I just focus on mine” and that kind of don’t look up and pay as much attention during stand-up meetings about what everybody’s status is. I think it all kind of wraps together. I need to make sure that I’m shouting out to the rest of the team if I’m having trouble on the ticket like I need help! You gotta come in and help me or someone else is – I need to be aware of that. And I’ve gotta get through my tickets, not just so I get my work done, but so I can go and help someone else. And I think when they’re pre-assigned, it’s easier to not be prepared to finish your ticket and then go look around and see who else needs help.

CHUCK: Yeah. The other thing that’s nice about that, too, is that I’ve seen the ticket assignment thing work okay in the sense that it’s like “Okay well, you’re an expert over here so you take all those tasks, and you’re an expert over here so you’ll take all those tasks”. Well what happened, it turns out that Jim and Chuck are working on the same project. And Jim takes all the A-type of stories and Chuck takes all the B-type of stories, and then somebody comes along and goes “That Jim guy’s a real smart guy, you know what. I want him to come work for me”, and so Jim leaves. Well then whoever they bring in doesn’t know anything about the A-type of stories and Chuck doesn’t know anything about the A-type of stories. So then what do you do? And so you need that mix…you need that blend. And so it seems like that’s the way it usually goes with the story assignment as opposed to maybe having a primary and secondary and the one on those topics at least. And so it’s like “Okay well Jim needs to spend a little more time on these other areas so that he understands them, and we’re going to let someone so — we’re going to let Eric take over the majority of the stories” if you’re going to assign them out anyway.

ERIC: Well another thing to keep in mind is kind of what stage the product’s at. Like if it’s at the early stage you wanna spread that around so everyone learns and there’s a lot of like “the cross-pollination”. But the late stage, I could be a Russian that gets to launch – pretty much getting the task done in time as more important than having two people know about a section. And that’s something that a good project manager would kind of figure out and realize like “Okay, we just need to crunch-do 10 bugs. Chuck’s really good at them, I’m just going to give them all to Chuck, let him bang through them one after another” because it might even be in his Axiom file he has opened at the same time versus at the beginning of the project, he mind to spread it around just so like “Oh, this way Jim can kind of figure out what’s going on” and there’s of “Chuck is sick for a week, next month Jim can step in” or that sort of thing. And that’s something that most people — I don’t know if most people don’t realize it or they don’t actually address it but, when the project stabilizes and stuff, they kind of tend to keep their development process the same even though the project itself has changed.

CHUCK: Yeah, that makes sense. And it makes a lot of sense. And I like that you point out that there are tradeoffs just like what everything else. So one other thing that comes to mind is sometimes you run into a pain; you run into something that is just not working. And you don’t know what the solution is. You don’t have the experience to sit down and just go “well, every other time we’ve seen this problem, we just solved it this way”. So my question then becomes, how do you find a good solution to a problem that you don’t completely understand?

ERIC: Oh one thing to do is like make sure you actually have that problem. I’ve seen a lot of imaginary problems come up and then if you really look at it and address it like from the business point of view, might not even be a problem. It could be a yak that someone’s trying to shave that they don’t realize having to shave the yak. That’s the first thing. Because if you can eliminate it completely, that’s going to save you so much time and energy. I don’t know — I mean typically prototypes are good for stuff – investigation stuff. I mean basically all you’re trying to do is increase your…like your understanding and your education on learning about the problem or what’s going on. So whatever you can do to do that, that might actually get you a solution forward.

JIM: Yeah I think that’s a really good point. Often people will — I’ve done this in the past I’m sure everybody has, you think like “oh I need to solve it this way” and if you don’t have someone else, considering those decisions, someone’s fresh mind might be able to point out to you “oh did you realize that we have this over here” and kind of obvious the needs for further development or change in the direction or whatever that you phantom problem you think exist.

CHUCK: Are there any other situations you guys have seen or heard about that you think might merit some discussion?

ERIC: Well there’s one thing I was thinking of is — we’ve talked about trying to change things and how to change them, what do you do if everything you can think of you tried, and the change still doesn’t happen? I mean, what happens at that point?

JIM: It’s a good question…You start looking for a new contract [laughs]

CHUCK: How much already have left?

JIM: [laughs] Yeah, I don’t know. I mean it’s really your satisfaction level – how desperately do you want the change to happen and how desperately do you need that work? I don’t know. I think it’s a lot of weighing those options. So, tough call! It’s really, really know what it say but if, I think, if there are people on the team who think about some particular problem the way you do who — maybe they see they don’t have to ask and they need continuous integration. But half the team thinks it’s a good idea, the other half thinks it’s a waste of time. You at least have these people who could help you maybe push forward, but if you’re the only one who’s [inaudible] and just think about some particular problem, then maybe that project isn’t the right fit for you and you should start looking elsewhere. I don’t know. There are a lot of things that go into deciding that, though.

CHUCK: Yeah I think a lot of it really does just boiled in and how much pain it’s causing you. I mean, if it’s annoying that they’re not listening to you, and slightly annoying that they still have that problem, but you can live with it and heck you’re only going to be doing this for a few more months anyway, yeah I mean just stick it out! If it’s something that you can’t just deal with anymore then, by all means, go find another contract and be there. Because apparently, either unwilling to deal with the problem that’s causing them the pain, or they are not feeling the pain. And you’re not going to change it in neither case.

ERIC: Yeah. So what about — how do you differentiate changes that you like to see in like management process versus development process? Is there a way you can affect change in a way a manager behaves for the rest of the development team? I think that is a lot harder to do.

CHUCK: Yeah I think a lot of it comes down unto whether or not you’re brought in as a consultant that’s going to change the overall process on things. I mean, you have agile coaches that come in and sometimes they wind up making changes to some management structure and things like that. On the other hand, if you’re just brought in as a developer, I mean most of the change that you’re going to be able to affect it — as far as like process and structure things like that is, really just within the team you’re in, and as much influence as you can manage on the people above you, so to speak, in their organization. So it gets real tricky above and beyond that. I can’t say that in some instances I’ve had some success with basically if there’s a role that I feel like needs to be filled. So for example, if it’s just one guy managing a dev team, and they don’t really have a project manager or something, I’ve stepped in and done a little bit of the project management stuff to make things easier. And what’s happened there is that I’ve wound up alleviating enough pain to where I could look at the manager then and say “Look, you know I’ve been doing the best I can here, but there are people who are trained for this that would do a 10 times better jobs than I am”. And once they feel that pain lift, then they’re willing to go and find a project manager or add the position. As far as changing where people are or what they do, that’s really really tricky. Even if you can clearly see that somebody belongs in a different spot to maximize their value to the team.

ERIC: Yeah I mean I don’t see like a management team or a management process and development team and development process as being that different. I mean it’s still the same kind of thing about proposing an idea and get pain, making them feel the pain around it. It’s different skills because you’re talking to different people and they value different things. But yeah, I mean it could just come back to that experience. I mean, do you have experience talking to people and management about management issues and getting them to make management changes. And as developers, we might not and that’s why it might feel harder.

CHUCK: Yeah it really just depends on your reach. I agree that a lot of times the management processes and the processes that happen on the development team really aren’t that different.

JIM: One thing I was forgetting about is choosing level of effort for stories. I’ve seen developers just choose their own story points like “oh, it’s going to be this” and not have any verification with the rest of the team. I don’t know if either of you play “Planning Poker”, but that’s a great way to have basically pure review on your estimations where you each — you all consider a story and come to your own guess about what the level of effort will be for your story points and then everybody lays down their number for what they think will be. And then sometimes you’re spot on and everybody agrees or sometimes there’ll just be this wild differences. And if you don’t have communication like that around planning for your sprint, and if I get some new ticket that track his work on all the time, I’ll look at him like “oh, that’s easy!” And then I’ll go to implement it and it takes me forever and I’m way late on it. It would’ve been probably caught if we had a planning proposition where Chuck and Eric and I all got to throw in on what we thought the level of effort would be.

ERIC: Though it’s more than just poker. I mean it’s — you should always have the individual doing the work, make the estimate. But you need to have the rest of the team weighing on it like in your example, Chuck would say “well no Jim, have you considered component X over here which would pretty much triple how much longer it’s going to take you to do it”. And on the other side is that you have to watch out like Jim and I might say like “oh this will take me a day to do” while if you get sick and have to pass that issue up to someone else, the other person, one might not have experience, might not be as skilled as you, or any number of other factors, and it might turn into a 3-day estimate for them. And so that’s — whenever I do estimates I try to do it like “this is what I think I can do it” to a sanity check of the other developers. And then if stuff gets passed around, it should be re-estimated at that point. And if it means stuff gets pumped up, pushed out of the iteration that might be which you have to do.

CHUCK: So when I’m estimating things, I’m usually not estimating, how long are they going to take? Usually I’m estimating points which is more of a how complicated is it. How big is the pile of dirt, is usually the metaphor used, as far as being able to do the estimations and getting people to estimate together. I mean we know the benefits of that, but all you really need to do, in my opinion, is go to whoever cares about the timeline and explain to them that if you can be consistent about the size of dirt that each story is, then they can accurately estimate, well somewhat accurately estimate, how long or how far out things are once you established a velocity for the team. And so if it’s a 3-point or a 5-point or an 8-point or whatever — most the teams I’ve worked with used fibonacci numbers that’s why I’m calling those numbers out — but what that does then is then they see value. They see value and having everybody estimate because if you estimate that pile of dirt and you get another story that’s about the same amount of work regardless of who does it. So if I do it, it takes me 4 hours and if I do the other story, it takes me about 4 hours. Provided I have enough information to solve the problem, then you can kind of get that idea “okay, we’re getting to the point where we’re getting a semi-consistent velocity”. And given how many points we can move through, then we can set that speed and so then you get buy-in from the top. And then they want that velocity, they want that predictability. And so then they can come down and say “look guys, we really do need the benefit of this offers” and then they can affect the change. But usually, you have to have somebody who sees the win for them and is willing to advocate it. If you’re just coming in and saying “this is the way we do it because we do it” then that doesn’t make sense. But yeah, if you can go and get a stakeholder that cares, then that works. And that works especially in this case where you go get that best stakeholder who cares about the schedule and then you sell them on velocity.

ERIC: Yeah I don’t know — I always try to take my time in making changes. Whenever I go on to a new project in particular, even if I’m hired to help simplify the process, I always just figure out how things are working already. I wouldn’t never wanna go in somewhere and say “alright, here’s how we’re going to do on our stand-up meetings”. I’d still wanna figure out how the team already works because if you don’t do that, then they’ll never trust that you’re there to help – you’re just that outside person. And once you leave, then they’ll go right back to do what they wanna do or though reluctantly drag their feet and do whatever change you suggested.

CHUCK: Yeah, absolutely. We are kind of at the end of our time, but I am willing to entertain any other things that you guys wanna bring up before we get into picks.

JIM: One strategy I’ve used, especially if you’re new, is if you’re coming in as a freelancer, you’ve probably work with more teams than on more projects than the developers there, so what I could sometimes do is still like on previous projects we’ve done stand-ups like this or another one we get it like of this. Basically put it out there as your examples of other ones I’ve seen and it’s kind of the good parts of these other processes. But if you’ve put it out there just as like that, then you can say “we can pick up any of these or none of these, but these are just some ideas that we can integrate into whatever process works best for you”. I found that kind of approach works good because you’re not actually saying “we need to change, you guys are doing stuff wrong”, you’re saying like “hey you guys are doing it this way, here’s some improvements we can look at – just that I’ve seen they may or may not work for you, but here’s the list of them”. And at the very least, I can get a conversation started and sometimes you’ll find out like “no, we have to do it our way because of…” some specific reason.

CHUCK: Yeah. And I like that. I like leveraging experience for that and employing out the benefits. But at the same time, it also helps when you can get the team to decide it, which I guess what you’re saying.

JIM: Yeah like you come to them with the idea but you leave the decision up to them.

CHUCK: Yeah. They are that’s what I was trying to say. Yeah because if they’re willing to try it, then you get the right kind of buy-in. If you get somebody that force it down their throats, then you might not make the [inaudible] that you want to. Alright well, let’s get to the picks! Jim do you wanna give us your picks real quick?

JIM: Yeah, I don’t have many of them, I just came across a link about a “Poor man’s guide to managing Ruby” which is just an interesting look at installing your own Ruby and how it loads and all that rather than looking at RVM and RBN and all of those other things up. There’s a lot out there and so I think it’s just a good read for getting to know what happens and…I think that’s it! I was going to pick was something like githubs, some obvious pick but you probably already know that now. That’s it for me.

CHUCK: Alright. Eric, what are your picks?

ERIC: I pick the internet. Everything on the internet is my pick. Damn! [laughs] No, just because what we’re talking about today I looked at a book that I’ve been having or have had on my desk for a couple of weeks. It’s an older one, it’s called “Extreme Programming Pocket Guide”, on Peter Shows you kind of might have heard that. I don’t care for a lot the upper case agile, heavy-ended processes, but this one I read years ago and I still keep me for intuit. Nice thing is it’s only like 80 pages and it kind of gives a good overview of extreme programming and like the different parts of it. And I fell on almost every kind of process I pulled out of this and put into whatever else I was working on in adept working good for the team and helped people out. So I’m going to pick it. It’s, like I said, it’s a short book you can kind of get through it in probably like one night of reading. And it’s nice as kind of a quick reference just to have nearby.

CHUCK: Yeah. Sounds good, I’ll have to check it out. So my picks today are — my first pick is “Practical Objects Oriented Design in Ruby”. It is a book by Sandi Metz. And we did an interview with her yesterday on Ruby Rogues and I have to say that it’s probably the best episode that we’ve done ever on the show. I mean it was tremendous. It’s also tremendous in length that we wind up going about 2 hours instead of the usual 1, sometimes we get up to like an hour and 10 or an hour and 15 minutes, but it was absolutely awesome. And I encourage you all to go and check it out. It will be out next Wednesday which — this gets released on Thursday so it came out yesterday. And that’s my only pick for today, I’m kind of low on picks. Is there any interesting that you’ve been working on Eric that you wanna talk about or should we just wrap up the show and say…[inaudible]

ERIC: It’s a new year; I’m busy, got a new laptop, but yeah, nothing really. Just been lot of client work.

CHUCK: Alright. Well then we will wrap this up and we will talk to y’all next week!

ERIC: Right. Take care!