Welcome back to another episode of The Rabbit Hole Podcast. Today we are talking about the evils of preassigning tickets! Here on the podcast we all agree that there is really no reason to do this and the practice is really just asking for problems immediately and further down the line. We discuss why exactly it is a kink in any system of any sprint meeting and the multitude of ways it can harm your team and their work. The conversation also covers the potential ways to get around the tendency towards preassigning and the team gives their personal opinions on best practices in this regard. Ultimately, the lesson here is to build a culture of collaboration and prioritizing the team’s progress and knowledge building. Preassigning is a just a way to inhibit this, so stop doing it! Listen in to hear all the reasons why!
Key Points From This Episode:
Transcript for Episode 91. Stop Preassigning Tickets
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsey, Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:12.3] MN: Today, we have an announcement. Stop, pre-assigning your tickets.
[0:00:18.0] DA: It’s stop part two.
[0:00:19.0] MN: Yeah, it’s stop part two of many parts. I think we’re going to start telling people to start doing things.
[0:00:23.7] DA: We will continue.
[0:00:25.9] MN: We will start them and then we will continue hopefully. Pre-assigning your ticket to something we have to stop together as a group, as a collective, as a community.
[0:00:35.0] WJ: 100% agree.
[0:00:36.1] DA: Yeah, pre-assign tickets, what does that mean to preassign ticket.
[0:00:40.5] MN: We could bring it all the way back to the beginning of the pre-assignment of tickets in the first place. Usually in an AGILE team, you’ll have a sprint planning where individuals will decide what pieces of work are going to get done, that includes the product manager, the project manager, all sorts of individuals responsible for pushing that work forward.
[0:01:04.2] DA: Yeah, it’s episode number three.
[0:01:06.5] MN: Episode number three, there you go, this guy. Remembers all the episodes, it’s that. Check it out.
[0:01:12.4] DA: I have them tattooed all over me.
[0:01:16.2] MN: When you have sprint planning, one of the things that happens is the amount of work that gets picked up, usually, you know your team’s velocity and you say, okay, we have suppose you do 20 points per sprint, we’re going to assign the 20 points that we feel prioritized and break. Like get to – we’ll go to work and choose our own tickets but oftentimes, in sprint planning, no one leaves the room until everyone of those tickets are assigned to an individual.
[0:01:45.7] DA: Man.
[0:01:46.5] MN: It’s pretty scary.
[0:01:47.9] WJ: So broken.
[0:01:48.7] MN: Let’s talk about that for a second, we’re going to argue about why it’s broken but let’s talk about why that is the norm for teams to want to do that.
[0:01:57.6] WJ: Well, I don’t know that I would say that it is the norm. I would say the vast majority of AGILE teams that I’ve been on, they actually haven’t assigned tickets. I definitely have seen it and it’s definitely not uncommon.
[0:02:10.2] DA: Yeah, in the past, I worked on a team where it was a bunch of mobile engineers and there was like one back end engineer. It’s like okay. Guess who’s doing this ticket?
[0:02:22.9] MN: Bobby backend, got all the back end stories.
[0:02:25.6] DA: The back end stories and then you know, Andy Andrew, I had got all the Android stories and you know, iOS guy to this thing.
[0:02:35.6] WJ: that’s a perfectly reasonable approach. I don’t think I would disagree with that, I mean, if you only have one person who is qualified to take the ticket and they’re going to be the one who takes the ticket.
I don’t’ know that we need to formality of like putting that person’s name on every single ticket in the sprint ahead of time but I also don’t think it hurts because that’s what’s going to happen anyway.
[0:02:54.5] MN: I think it has to do with like the idea that people may be able to take up X amount of work throughout the sprint and ensure that the work gets spread out I guess. I think with those different like tech stack silos, are examples when you want to preassign tickets but if it’s like, everyone can do the work but then you preassign that can be a little shaky.
[0:03:17.0] WJ: Yeah, I mean, how often are you really on a team where none of the engineers have any overlap of skillset? I feel like that’s pretty rare.
[0:03:24.9] DA: Yeah, hopefully you have at least some other buddy that you can turn to.
[0:03:29.6] WJ: Yeah, I mean, if you were the only engineer who understands how to do that type of code and you’re in – you’re by yourself, you’re not going to have anybody to go to for advice. Things like maybe you need to hire somebody.
[0:03:38.6] MN: In that regard though, there may be, even though people can overlap a certain skills, there are parts of the domain that people may be more familiar with. Suppose I’m the product manager - all right, I’m the project manager and my job is to ensure that the work gets done as fast as possible.
Wouldn’t I want to make sure that the people who are assigned to the work is doing the work that they’re most familiar with? So that we ensure that we get this sprint done and completed.
[0:04:10.0] DA: Yeah, I’ve been on that situation too where I became the time lord. It was like the worst episode of Dr. Who and I just – that was the guy who like – this guy understands time zones. Was like a ticket for me.
[0:04:30.9] MN: How did you feel about that, about being the time lord?
[0:04:34.8] DA: I mean, it was a really extravagant title but I really didn’t feel like I wanted it. It’s a little frustrating because it’s a very complicated domain and like, you want to build like spread out that knowledge. When you figure something out, the more you do that, the deeper you dig your hole of expertise that you can never get out of. You can never go work on a drop down again. You’re only working on like timezone related edge cases.
[0:05:05.7] WJ: I think that oftentimes, when we try and optimize for velocity instead of for building the right thing and building it well, is we sometimes end up accelerating when we’re already off course. When you accelerate while you’re already off course, you just end up lost faster.
[0:05:23.9] MN: I see. By picking up all the work that you had, when you get delayed on something, you’re only further behind. I think that it encourages you to work on the wrong thing because when you preassign tickets, an individual team member has tickets blocked.
[0:05:41.1] DA: Right.
[0:05:41.5] WJ: They’ve effectively blocked those tickets arbitrarily on wherever they happen to be working on right now and nobody else picks those tickets up, even if they’re higher priority.
What oftentimes you see is there will be somebody on the team who is actually finished all of their work and they’re picking up bug tickets and little things that don’t matter or going back and fixing things that they wrote the last time that they were really slammed and had to cut corners because they actually underestimated how long things were going to take.
At the same time, you’ve got someone else who is totally slammed, is definitely going to miss their sprint commitment and is pushing out low quality work into production. If the ticket were just not preassigned, the person who is free could step in and help out the person who is struggling.
[0:06:25.8] MN: Right, I think like, as you mentioned before, if person A is working on stories that you know, the first two may have been higher priority but then those next two were lower priority but person B has things that are higher priority on average. Person A can’t take those stories because they’ve already been preassigned to person B which is a problem.
Then you do pickup you know, those bug fixes that just ends up not being more helpful than the prioritized work that needs to get done.
[0:06:55.2] DA: Yeah, that person who is really good at timezones, who always get the timezone tickets, eventually, switches teams or you know, switches companies and all of a sudden, there’s this huge pile of code that no one else understands.
Really it discourages collaboration.
[0:07:12.6] MN: The time lord dies.
[0:07:15.0] DA: yeah, I totally feel you about the bugs too. Where they could be a low hanging fruit or you could just end up piling all these weird edge case and all on somebody. That’s when we need a batman, episode number 30.
[0:07:32.6] WJ: Question it with the episode callbacks.
[0:07:35.7] DA: Yeah, all those tats.
[0:07:37.5] MN: The tats. Yeah, I think like you know, as you mentioned before, person get removed from the team. I think the one thing that I always go back to when it comes to stuff like preassigned work is the idea of bus factor. Because if a person is a lord of a particular part of the domain then that’s a huge problem in the event that person gets hit by a bus.
You always want to make sure that your team can still survive and can still push high quality code if one person steps out of the team for X amount of time.
[0:08:10.3] DA: Right, yeah, whatever shape that bus may take.
[0:08:12.8] WJ: Wedding shaped busses.
[0:08:15.8] DA: Vacation shaped busses.
[0:08:17.0] MN: Trolley buses. I think one of the things that preassigned tickets causes is the inability for the team to help other people out on things.
[0:08:32.0] WJ: Totally.
[0:08:32.9] MN: Because when you’re preassigned to work, you know the amount of cards that are held against you, so you want to make sure that you get these stories done. So you inadvertently do not take requests from anyone because you want to make sure your work gets done.
Even like the little bits of like hey, do you have a second, do you have five minutes, can we pair for a Pomodoro on this one thing? You would more likely say nope, I got things I need to get done, so I cannot help you at the moment.
[0:09:04.4] DA: Yeah, it’s my bottom line.
[0:09:05.8] MN: It becomes a huge problem and like, helping each other, helping their team is like for me, it’s the utmost important thing because at the end of that sprint, it shouldn’t be, I was unable to finish these stories, it should be, we were unable to finish these stories.
[0:09:22.7] WJ: Yeah, I think even worse than the fact that preassigning tickets incentivizes you to not help other people because doing so makes it easier for you to finish your own work, but it actually makes it so that you benefit when your teammates can’t get their tickets done. Because it reduces everybody else’s velocity and makes you look relatively better.
[0:09:46.5] MN: Wow, yeah. It’s like yeah, I managed to finish all my stories, why couldn’t any of you do it? It becomes one of those.
[0:09:52.8] WJ: Why bother training somebody up if all of a sudden, they’re going to be pulling in 20 story points and you’re only pulling it in 10?
[0:10:00.3] DA: Yeah, that’s kind of interesting, the times I think that you – it’s hard to control people’s behaviors but if you design the environment in a way, the process in a way, you encourage certain behaviors, incentivize certain behaviors. [inaudible] like – it emphasizes the achievement of the individual over the achievement of the team, which maybe a more useful incentive to have.
[0:10:26.3] WJ: Yeah, I mean, it’s like, that basketball player who is bragging about his personal point count when his team lost the game.
[0:10:33.1] MN: Yeah. Stop being a ball hog, do your work, help the team.
[0:10:37.7] DA: Get all those rebounds.
[0:10:38.4] MN: Yeah. Pass the ball around, guy. Yeah, you have to make sure that the rest of the team is doing well to get those story points then. I think it incentivizes people to turn their backs on their own teammates to make sure that they look good.
[0:10:52.9] DA: Yeah, another thing that might happen that would encourage people to assign tickets ahead of time, there might be like multiple computing priorities. We have to do these three things, these three epics needs to get done, okay. Mike, you do this one, William, do this one and I’ll do this one.
[0:11:13.0] MN: Right.
[0:11:14.5] DA: Then that kind of eliminates the ability for collaboration and for parallelization of the work and you're going to end up with three things that are not done as supposed to one thing that – ideally, if there are things that could work in parallel than me, you could get it done quicker.
[0:11:31.4] MN: One can parallelize the, all the work together in that rather than having three shortly delivered work by three different individuals, you can have like a one epic that’s done with three different people’s hands tied into that work. Then be able to deliver the next one and then the next one.
You can actually like roll out these features, let’s say one sprint at a time. Rather than slowly building those things up side by side and then really seeing those three in three weeks, in three sprints rather.
[0:12:08.3] DA: Yeah, getting quicker value out of the code, like getting it out the door, that’s more lean.
[0:12:13.5] MN: Right. Got to get that work out the door, get them features out. Do you have any other thoughts on why we shouldn’t preassign tickets?
[0:12:22.4] WJ: Yeah, I think it also breaks whip limits or discourages low whip counts. Meaning that people start a lot of tasks and then do a lot of context switching between all of them because they know, no one else is going to take those tickets. They have to get them done. You try and parallelize and do too many things at once.
I think there’s a lot of literature in the AGILE world that talks about the importance of eliminating working progress because work in progress leads to waste.
[0:12:50.5] DA: Seven wastes, episode number 80.
[0:12:53.7] WJ: That is amazing.
[0:12:55.6] DA: Sorry, 82.
[0:12:59.8] WJ: That’s a little smudge on the tattoo.
[0:13:01.5] DA: There you go. Really gotta get a touch up. Yeah, totally. Again, that team focus changes your perspective on pulling more work in progress because like, you’re impacting the team, you’re stopping that work from getting done by someone else and you may be stopping the team from fulfilling their commitment by like having all these plates in the air at once.
You’re discouraging something that is bad by the system that you're designing.
[0:13:34.8] WJ: It makes it really easy when you are blocked to just switch over to one of your other many tickets as supposed to actually pursuing why you’re blocked and getting unstuck.
[0:13:45.4] MN: I think one of the things you had mentioned you have too many work in progresses going on and I think when that occurs, you’re more likely to have done much more work in one big chunk rather than chopping it up into little pieces for poll requests which then causes a person to take their time off the day to review your code and it takes a lot longer because you have all these different work in progresses that you’re trying to merge in all at once and whatnot.
That causes more time to be spent on reviewing and that kind of stuff when you can pretty much compartmentalize all the features that needs to get done bit by bit and can be reviewed really quick, merged into master, pick up the next one, rather than having them in big chunks. I think there’s another reason why you don’t want to have so many whips at the same time.
Yeah, I think overall, it just encourages people to not be team members, are you just being really selfish about getting all of this work that was assigned to you? Rather than helping individuals out. I think when you are preassigned tickets then your team is less likely to do pair programming because you’re so caught up in the work that you need to get done that you’re unable to pair with anyone else.
I think that knowledge transferring is very important and teams miss out on that because of the preassignment that happens in sprint planning.
[0:15:13.3] WJ: My God, yeah, why would you volunteer to pair with somebody else on their ticket? That’s just going to put you behind on your ticket.
[0:15:18.3] MN: Yeah, I need to get my work done. You're not helping me, I’m helping me.
[0:15:23.7] DA: Yeah. You could also have a case where people are choosing the tickets, they could like strategically choose all the tickets that are like, pretty easy and then you end up with people having to pre-commit to ambiguous or challenging tasks.
[0:15:40.8] WJ: Yeah, absolutely. Sand bagging, great move in this system, if you’re preassigning tickets, definitely try and pump up the story points on the tickets that you pull and try and make sure that the tickets you pull are actually really easy because that’s the best way to make sure that you meet your commitment.
[0:15:56.2] MN: Right.
[0:15:57.6] DA: Yeah, although, again, if you have a team focus, then that kind of thing isn’t so bad, it’s fine if you are like good at identifying inefficiencies in the team’s estimate because you’re just fulfilling the team’s commitment.
[0:16:14.2] WJ: It’s also way easier to handle little hiccups like if you get sick and are out for two days, all of a sudden, your sprint commitment is way harder to me, whereas for one member of a team is out for two days, it doesn’t have that big of an impact.
[0:16:26.7] DA: Right, yeah, that does feel pretty good when you can be out of the office and people are like, I don’t really care, I’ll miss you, love you but don’t come back sick. Right, or just to go away for two weeks and come back and go it didn’t really matter, that’s fine.
[0:16:46.2] MN: All right. I think we’ve been mentioning why you should stop preassigning your stories. I think we’re all somewhat in the same space right now. We can all agree that we have told everyone to stop preassigning their stories to their engineers because of all the cons that we just mentioned.
William, from the top, we just finished sprint planning and we realized that we’re going to take X amount of points into this week’s sprint. What happens after that meeting?
[0:17:20.9] WJ: I think that you should pick up the first ticket that’s close to the top of the queue as you are qualified to handle. If the number one ticket is an Android ticket and you are an iOs developer then skip that one. They should be ranged in priority order and so you should be able to easily tell what’s the best use of your time right now.
I think during the planning meeting if you want to assign any of the tickets that have to be assigned or if you want to assign a first ticket to everybody, that seems perfectly reasonable.
[0:17:50.3] MN: Right.
[0:17:51.0] WJ: Art’s just when you're trying to sign everything for the entire sprint commitment. The sprint commitment is a team commitment. Jeff Sutherland was very clear about that in his original work, the original book on scrum.
[0:18:03.1] DA: Yeah, scrumguide.org.
[0:18:04.9] WJ: Absolutely.
[0:18:06.4] DA: One of the finest Jeffs.
[0:18:08.4] MN: The finest of Jeffs. Yeah, but it becomes a team commitment. That’s a good strategy too, as long as people can have a discussion in the sprint plan and then say okay, let’s all pick one story right now from the top and then we’ll assess every day, every morning, during standup, to determine where we are in that story and whether we can pickup the next high prioritized work.
I think that with that in mind, even that system right there feels a lot more graceful, I don’t want to think that’s the word. Because you’re able to pull in the work that you want to do or that the work that you can do. Or the work that you’re interested in learning about, rather than being pushed down on the work that you have to get done and that you must do before the end of the sprint.
You pick things up by prioritization, whether you know it or not, if you're incapable of writing that code then you’re going to learn and everyone learns that way, the knowledge silo dissolves and everyone starts learning about the code base.
[0:19:12.0] WJ: Becomes much easier to pair because doing so doesn’t hurt you, it just helps the team.
[0:19:17.0] DA: Yeah, definitely. It feels really good when you get on a team that matures and trusts each other and has a collective code ownership where they’re able to comfortably work on most of the areas of the code base is now all of them. First there’s still going to be expertise, there’s still going to be somebody who has some more specific experience with a domain but given that the whole team has promised to do the thing. That person could be a resource to push people out.
[0:19:48.1] WJ: Collective code ownership. Keep part of that.
[0:19:51.7] MN: Think about this for a second, this just dawned on me, imagine you were working in a team and it was preassigned work and all the work that your other engineers got were high prioritized work that seemed like things that you really wanted to learn but if you're new to the team and new to engineering, you just got all the bug fixes.
That’s not fun either, right ? you just, in the background, dealing with bugs or the low hanging fruit, you’re not working on like highly prioritized work or like this new feature that’s coming out. When you’re preassigned those tasks.
[0:20:24.7] WJ: It’s the slowest way to ramp up on a team. Work on the least important stuff by yourself.
[0:20:29.6] MN: Yeah, exactly. I think that when you work on prioritized stuff that’s picked off from the top of the queue. You had your hands in like a feature that, you know, can potentially bring your organization value and you had the opportunity to work on that because you were free to do it, you know how to do it or you were interested in learning how to do it.
When you get preassigned tasks like you may get the short end of the stick. The short straw, you may get the short straw I think it’s called. I don’t’ know. I never picked straws before. I don’t know anyone in this room who has picked straws before but I definitely wasn’t one of them. If you got a short straw then you get all the bug fixes and all of the little stuff. Not the fun work that gets done.
[0:21:14.7] DA: We did a demo today and on my team and we were looking at the page and okay, who is the person who has the most context to demo this page? Looking at it, its’ like hey, actually we all kind of came together and built little pieces of this thing and it all kind of came together in the end.
Yeah, it felt really good, something to be proud of.
[0:21:36.8] MN: Yeah, that is awesome because like, imagine, you had to give this demo tomorrow but then this morning, you were unable to make it to the demo then the demo doesn’t get presented or no one’s capable of giving the demo of this page, Right? The bus factor. I’m sorry, if you got hit by a bus in the morning, you're unable to give this demo then whoops, there’s no demo presentation then that sucks. Don’t get hit by a bus Dave is what I’m saying, please.
[0:22:04.9] DA: I hope there’s more than worry. Let’s hope the demo happens, you know?
[0:22:12.6] MN: Yeah, I mean, it’s more like when it happen when the knowledge is shared across the entire team but don’t get hit by a bus Dave, please.
[0:22:19.4] DA: I’ll try to look both ways.
[0:22:21.5] MN: Both ways, look everywhere. Above you.
[0:22:24.5] DA: It’s very busy at 32nd street, I really try my best although I do jay walk.
[0:22:30.1] MN: Yeah.
[0:22:33.0] DA: couple of near misses but you know, I haven’t been hit yet.
[0:22:35.5] MN: There you go. No longer preassigning my stories, I finished the one story that I was assigned, it’s done, it’s shipped to production, what next?
[0:22:46.3] WJ: Now you pick up the next ticket that’s highest up in the queue that you feel qualified to tackle and if you change your mind partway through, that’s okay too, in fact, the daily scrum meeting, your standup meeting is a perfect time to do that.
Jeff Sutherland actually wrote about this very topic. The daily scrum is held every day of the sprint and at it, the development team plans to work for the next 24 hours, that’s what they say on scrum.org.
[0:23:13.4] DA: Working at an AGILE way is all about maximizing feedback loops and like making them as tight as possible. If you have a two week commitment and you’re committing each person ahead of time, you don’t really leave much room to iterate and like see what’s actually happening.
Because you’re going to find out more as you get into it, you may have become blocked, I made the react to change, you may need like help from somebody on a different thing. Fixing it at 24 hours really helps you have that regular time to do that.
[0:23:47.5] WJ: Yeah, you really free yourself to use your time as efficiently as possible by allowing yourself to change your mind every 24 h ours about what the best use of your time is.
[0:23:56.1] MN: That way you can give an update to your team and everyone agrees and then you continue delivering high quality software at the end of the day. There’s just something about preassigning work that feels like it’s more of an ‘I’ thing rather than you know, picking up the things of the most highest priority and it becomes a ‘we as a team’ thing.
Because if you have the highest prioritized piece of work and you need help, the team’s best interest is to help you unblock that work and then everyone comes together to ensure that that piece - that story gets done at the end of the day. Then the daily scrum, you can update again, hey, I’m working on this thing or I have a blocker, please help, that kind of thing or I’m good, still working on it, should be done by the end of the day, boom, done. Standup over, ship it, all the things.
All right, we’ve been telling people to stop preassigning the work but what if me as an engineer, I want to do all the cool stuff. Why don’t I preassign myself to all the cool stuff of the highest priority and I get to ship all the nice features that come out. What do you got to say about that?
[0:25:10.4] WJ: Well, I think that’s a great idea for now, right? In your immediate future, that’s going to be wonderful because not only do you get to do cool stuff but you can make sure that you have all of the expertise in the coolest stuff so that it always makes sense for you to work on that cool stuff and then it’s easy for you to sandbag so you can make sure that you’re not taking in too many story points and you have a little bit off extra slack.
The problem comes later on when you want to work on a different kind of cool stuff or when your team ends up performing worse over the long run and starts missing deadlines and it doesn’t matter that you personally always hit your sprint commitment and you personally get to work on this one section of the codebase that you really like because when the team’s not happy, nobody’s happy.
[0:26:00.9] MN: Because at the end of the day, I mean, I was going to tell you to just fire those people. Because I’m doing all the work and I’m shipping all the cool stuff but the thing is as you mentioned, the team won’t be happy because we’re under-delivering, on certain things.
[0:26:16.5] WJ: It doesn’t matter how many points you score, if your team loses, you lose.
[0:26:20.6] MN: I don’t lose.
[0:26:22.2] WJ: All I do is win.
[0:26:23.6] MN: All I do is win, no matter what. Yeah, There is some sacrifice in the – I mean, short term as you mentioned, yes, it’s cool, it’s fun, I get to do them if I put it so myself. Or I ask to do those because I’m so good at it. You don’t share that knowledge with everyone and it becomes a problem when the team doesn’t win.
[0:26:44.2] WJ: It’s like doing drugs.
[0:26:45.1] MN: Share it, is that what you’re saying? Share the drugs?
[0:26:47.7] WJ: It may feel good now but in the long run, it’s very bad for you.
[0:26:52.5] MN: Don’t do drugs kids.
[0:26:53.1] WJ: Don’t do drugs.
[0:26:53.9] MN: Whatever you do.
[0:26:55.1] DA: Next episode, stop doing drugs.
[0:26:58.7] WJ: Next episode, which is worse? resigning tickets or heroin?
[0:27:03.8] MN: Yeah, I don’t know. Preassigning the ticket, why choose?
[0:27:11.0] WJ: How do you convince me not to take all the cool tickets?
[0:27:14.4] MN: I think it’s up to the individual themselves, right? We have to understand why this person wants all the tickets, is it because they really want to do all the cool stuff, learn everything and not share it with their team? That’s kind of like wrong, I think that an individual who wants to do that should be able to share that information. If that person wants to look good and have all the points and then sandbag, then that’s like an employee problem.
That person just wants to look good or like, stay up to par with the rest of the organization because they look good. I would ask that person to work with individuals, if they’re going to take all those tickets then they have to do like a lunch and learn. Everyone has to learn what’s going on or everyone has to get a piece of that particular cool story work, so everyone can have some fun too.
[0:28:04.1] WJ: Yeah, I mean, I usually believe that people are inherently good and they usually want to do the right thing and usually when people end up becoming knowledge silos, it’s not because they sort of selfishly want to hog cool work, it’s usually more of a trap that people fall into by mistake. You're good at a thing, you should do more of it, right? It’s like –
[0:28:25.7] MN: I mean yeah.
[0:28:26.2] DA: Helping but delivering this.
[0:28:28.2] MN: You have a time lord in the room who was time lord, all the time.
[0:28:33.2] DA: For life.
[0:28:36.4] WJ: He was helping people.
[0:28:37.1] DA: William, do you have any time problems in the project document? I can do those problems.
[0:28:42.0] WJ: It’s tough, you know? It’s like in the phoenix project, remember Brent? You know, the guy who got saddled with all the work because he was just the best at it? Working on saddle with it, the better he got at it and the harder it was for –
[0:28:54.1] DA: It seemed like he was the hero of the story at first but actually, he was the villain. Tragic hero maybe.
[0:29:02.6] MN: Trying to convince individuals to not take all the cool work, that has to be disseminated across the entire team. Everyone needs to have fun.
[0:29:11.0] WJ: I think you got to appeal to people’s desire to do right by their teams which I think people generally have.
[0:29:16.9] MN: You have to make sure that even if you come across people who don’t that they still have to.
[0:29:23.5] DA: I do like pair programming too for spreading out cool work. Because then, you don’t have to fight, you can both – two people can do it, you can rotate, like as long as the stuff is getting done then you know, everybody has some ownership.
[0:29:37.7] WJ: Sharing is caring.
[0:29:38.8] DA: Contribute to a review.
[0:29:40.3] MN: Unless that person always wants to drive and forces you to always navigate, that’s a whole other episode though, I’m sure of it.
[0:29:48.4] DA: Let me check my tattoo.
[0:29:52.0] MN: Check the one under your arm or hold on, let’s get a mirror and make sure that we -
[0:29:59.6] DA: Is it number four.
[0:30:01.9] WJ: Number four is usually a pretty good guess.
[0:30:06.1] DA: Just a really – surprised we haven’t had more but II guess we always talk about performing somewhere.
[0:30:12.5] MN: Pairing is a great way to you know, ensure that everyone has fun with all the cool work.
Ladies and gentlemen, please, tell your project manager, stop preassigning the work for you. Tell them, hey, don’t tell me how to live my life, all right? I’m going to pick up the stories of the highest priority, I’m going to get stuff done as a team.
[OUTRO]
[0:30:36.3] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources:
