Project Management | Jeanine Jue

So we're gonna do a little bit about project management, Agile. I'm not a huge fan of processes at a very early stage of the game development, because you gotta get it out. You only have 3 to 6 months. So everybody follows the Lean Startup model, the Agile methodology, and I'll send you these slides too, so don't worry about it. So again, just going through the whole cycle of it and breaking down feedback review. You wanna leave developers out of this. in terms of what's going on, putting together requirements, everything like that. In some cases, depending on what level your developer's at, it's always best just to give them the requirements, give them the features. They hate meetings. That's why it's best just to have those 5-minute meetings. Just keeping it in too much process for them, they hate. It'll kind of just discourage them from wanting to continue to do development. Again, the requirements analysis, design doc, and prototype. If they want to be a part of it, that's great, because you really want to make them feel like they're part of the team, but don't hold them accountable for writing requirements if that's not, or design doc a prototype if that's not something they want to do. Another thing too, it's up to you to make sure these requirements are clear for them because there's constantly misinterpretations of requirements, especially when it comes to here all of a sudden you have your build and then the requirements are not aligned, so it's like, this isn't what I was asking for. Giving developers structure. Giving developers structure. They do need structure. They do need tools. They need to be held accountable. You can't really see this too well. This is Jira, Jira tool, and then you have the Bugzilla tool. I always keep it simple. The more complex the tool, the more they're not going to use it. But you just want to have that social aspect. It's like, oh yay, like a to-do list. If you could just keep it as simple as that. Small as a to-do list. And especially with Bugzilla, you have to fill out priority and stuff like that. Keep it simple in terms of what parts they need to fill out. If they're gonna add a bug or a new feature, if you're gonna add stuff, you just wanna be like, hey, listen, just pay attention to this, and these are the steps and how it's happening. Stuff like that. Code reviews. There are so many startups that don't do code reviews. I am shocked. And then you look at the code base and it's an absolute mess. Well, good luck to you 1, 2 years down the road when you're trying to scale, you got additional funding. 'Cause I've worked with companies, they've had to rewrite their code because they didn't have code reviews. Well, we didn't think it was important, or we only had a few people on our team. It matters. It matters from when you first write that line of code. Daily standup meetings. Yeah. Don't leave the engineers off in the drift. Even if they're remote. That's really important to always keep them engaged. Utilize Slack. Make sure there's a communication tool. And again, if you're CEO, if you're on the business side, get on Slack. You wanna see those communications. The more communications, like, yeah, they're really getting stuff done. And you can have a better idea in terms of what your developers are up to. Keeping track of their tasks through the tools. Developers hate documenting. I do too. They hate documenting stuff. They hate commenting their code. And it's really important because, and this has happened. I'm an advisor for a startup. And the developer, the lead developer, he was building all this stuff. And I'll get into the details of it later. But he built all this stuff. He was the lead developer. He died. Okay, he died right at the funding round. And so now they're trying to, Figure out— first they had to go to the families, try to get the code, and it was just really like a traumatic experience. And there was no documentation. There was no knowledge transfer. So they actually had— they pretty much had to toss it. But I mean, that's like an extreme circumstance. But something to keep in mind, anything can happen. So make sure you have as much information available as possible in order to continue your startup. So here's high level what I would do for giving developers some structure. If it's task-oriented, set realistic goals for them. Assign 3 tasks. If you're gonna come up with time estimates, work on it together. Always add a 25, at least a 25% buffer. If a developer says, yeah, this is gonna take me 8 hours, we are so full of it. Always add at least 25 to 50%. Onto their estimates in terms of how long it's gonna fix. Time estimations, also estimate in terms of the lines of code. If they could be like, okay, how many lines of code is that bug gonna take you? Sometimes they don't know, but they could throw out a general number, which could be relatively close. Daily standup meetings, weekly review meetings. But any requirements discussion, anything like that, we hate it. Just keep us out of it. And again, rewarding developers. Training, even have them— this one startup I was working at, I was advising, the girl wanted to learn— the guy wanted to learn Node.js. It's like, wow, even though he was an iOS developer. It's like, come on, Lynda.com is like $300, and if you go to one of those local classes, only $500. It saves you. having to increase their salary by 30 to 40% just by having all these little perks for them. Online memberships, as I mentioned before, experts exchange, hackathons. If you pay a developer, I'll pay for your flight. They're going to a hackathon. If they win it, I mean, how cool is that? People will know what your company is. Have them go to every frickin' hackathon, wear the company shirt. You're evangelizing yourself. Yourself too. And that's why even attending, presenting at conferences, those technical conferences are just really important for visibility of your company. So that would be a huge thing if you could potentially give them a shirt and let them go around and go nuts.